Man page - aptly(1)

Packages contains this manual

Package:  aptly
apt-get install aptly

Manuals in package:
• aptly(1)
Documentations in package:
• aptly

Manual

APTLY

NAME
SYNOPSIS
DESCRIPTION
CONFIGURATION
PACKAGE QUERY
PACKAGE DISPLAY FORMAT
GLOBAL OPTIONS
CREATE NEW MIRROR
LIST MIRRORS
SHOW DETAILS ABOUT MIRROR
DELETE MIRROR
UPDATE MIRROR
RENAMES MIRROR
EDIT MIRROR SETTINGS
SEARCH MIRROR FOR PACKAGES MATCHING QUERY
ADD PACKAGES TO LOCAL REPOSITORY
COPY PACKAGES BETWEEN LOCAL REPOSITORIES
CREATE LOCAL REPOSITORY
DELETE LOCAL REPOSITORY
EDIT PROPERTIES OF LOCAL REPOSITORY
IMPORT PACKAGES FROM MIRROR TO LOCAL REPOSITORY
LIST LOCAL REPOSITORIES
MOVE PACKAGES BETWEEN LOCAL REPOSITORIES
REMOVE PACKAGES FROM LOCAL REPOSITORY
SHOW DETAILS ABOUT LOCAL REPOSITORY
RENAMES LOCAL REPOSITORY
SEARCH REPO FOR PACKAGES MATCHING QUERY
ADD PACKAGES TO LOCAL REPOSITORIES BASED ON .CHANGES FILES
CREATES SNAPSHOT OF MIRROR (LOCAL REPOSITORY) CONTENTS
LIST SNAPSHOTS
SHOWS DETAILS ABOUT SNAPSHOT
VERIFY DEPENDENCIES IN SNAPSHOT
PULL PACKAGES FROM ANOTHER SNAPSHOT
DIFFERENCE BETWEEN TWO SNAPSHOTS
MERGES SNAPSHOTS
DELETE SNAPSHOT
RENAMES SNAPSHOT
SEARCH SNAPSHOT FOR PACKAGES MATCHING QUERY
FILTER PACKAGES IN SNAPSHOT PRODUCING ANOTHER SNAPSHOT
REMOVE PUBLISHED REPOSITORY
LIST OF PUBLISHED REPOSITORIES
PUBLISH LOCAL REPOSITORY
SHOWS DETAILS OF PUBLISHED REPOSITORY
PUBLISH SNAPSHOT
ADD SOURCE COMPONENTS TO A PUBLISHED REPO
DROP PENDING SOURCE COMPONENT CHANGES OF A PUBLISHED REPOSITORY
LISTS REVISION OF PUBLISHED REPOSITORY
REMOVE SOURCE COMPONENTS FROM A PUBLISHED REPO
REPLACE THE SOURCE COMPONENTS OF A PUBLISHED REPOSITORY
UPDATE THE SOURCE COMPONENTS OF A PUBLISHED REPOSITORY
UPDATE PUBLISHED REPOSITORY BY SWITCHING TO NEW SOURCE
UPDATE PUBLISHED REPOSITORY
SEARCH FOR PACKAGES MATCHING QUERY
SHOW DETAILS ABOUT PACKAGES MATCHING QUERY
CLEANUP DB AND PACKAGE POOL
RECOVER DB AFTER CRASH
HTTP SERVE PUBLISHED REPOSITORIES
START API HTTP SERVICE
RENDER GRAPH OF RELATIONSHIPS
SHOW CURRENT APTLY’S CONFIG
RUN APTLY TASKS
SHOW CURRENT APTLY’S CONFIG
ENVIRONMENT
RETURN VALUES
AUTHORS

---

NAME

aptly - Debian repository management tool

SYNOPSIS

Common command format:

aptly [ global options ...] command subcommand [ options ...] arguments

aptly has integrated help that matches contents of this manual page, to get help, prepend help to command name:

aptly help mirror create

DESCRIPTION

aptly is a tool to create partial and full mirrors of remote repositories, manage local repositories, filter them, merge, upgrade individual packages, take snapshots and publish them back as Debian repositories.

aptly’s goal is to establish repeatability and controlled changes in a package-centric environment. aptly allows one to fix a set of packages in a repository, so that package installation and upgrade becomes deterministic. At the same time aptly allows one to perform controlled, fine-grained changes in repository contents to transition your package environment to new version.

CONFIGURATION

aptly looks for configuration file first in ˜/.aptly.conf then in /usr/local/etc/aptly.conf and /etc/aptly.conf . If no config file found (or they are not readable), a new one is created in the home directory. If -config= flag is specified, aptly would use config file at specified location. Also aptly needs root directory for database, package and published repository storage. If not specified, directory defaults to ˜/.aptly/ , it will be created if missing.

With aptly version 1.6.0, yaml configuration with inline documentation is supported and recommended (see debian/aptly.conf ).

The legacy json configuration is still supported (and also supports comments):

// vim: : filetype=json
// json configuration file with comments
// validate with: sed ’/\/\//d’ aptly.conf | json_pp
{

// Aptly Configuration File
////////////////////////////

// Root directory for:
// - downloaded packages (‘rootDir‘/pool)
// - database (‘rootDir‘/db)
// - published repositories (‘rootDir‘/public)
"rootDir": "˜/.aptly",

// Number of attempts to open database if it’s locked by other instance
// * -1 (no retry)
"databaseOpenAttempts": -1,

// Log Level
// * debug
// * info
// * warning
// * error
"logLevel": "info",

// Log Format
// * default (text)
// * json
"logFormat": "default",

// Default Architectures
// empty array defaults to all available architectures
"architectures": [],

// Follow contents of ‘Suggests:‘ field when processing dependencies for the package
"dependencyFollowSuggests": false,

// Follow contents of ‘Recommends:‘ field when processing dependencies for the package
"dependencyFollowRecommends": false,

// When dependency looks like ‘package-a | package-b‘, follow both variants always
"dependencyFollowAllVariants": false,

// Follow dependency from binary package to source package
"dependencyFollowSource": false,

// Log additional details while resolving dependencies (useful for debugging)
"dependencyVerboseResolve": false,

// Specifies paramaters for short PPA url expansion
// empty defaults to output of ‘lsb_release‘ command
"ppaDistributorID": "ubuntu",

// Codename for short PPA url expansion
"ppaCodename": "",

// OBSOLETE
// in aptly up to version 1.0.0, package files were stored in internal package pool
// with MD5-dervied path, since 1.1.0 package pool layout was changed;
// if option is enabled, aptly stops checking for legacy paths;
// by default option is enabled for new aptly installations and disabled when
// upgrading from older versions
"skipLegacyPool": true,

// Aptly Server
////////////////

// Serve published repos as well as API
"serveInAPIMode": false,

// Enable metrics for Prometheus client
"enableMetricsEndpoint": false,

// Not implemented in this version.
// Enable API documentation on /docs
//"enableSwaggerEndpoint": false,

// OBSOLETE: use via url param ?_async=true
"AsyncAPI": false,

// Database
////////////

// Database backend
// Type must be one of:
// * leveldb (default)
// * etcd
"databaseBackend": {
// LevelDB
"type": "leveldb",
// Path to leveldb files
// empty dbPath defaults to ‘rootDir‘/db
"dbPath": ""

// // etcd
// "type": "etcd",
// // URL to db server
// "url": "127.0.0.1:2379"
},

// Mirroring
/////////////

// Downloader
// * "default"
// * "grab" (more robust)
"downloader": "default",

// Number of parallel download threads to use when downloading packages
"downloadConcurrency": 4,

// Limit in kbytes/sec on download speed while mirroring remote repositories
"downloadSpeedLimit": 0,

// Number of retries for download attempts
"downloadRetries": 0,

// Download source packages per default
"downloadSourcePackages": false,

// Signing
///////////

// GPG Provider
// * "internal" (Go internal implementation)
// * "gpg" (External ‘gpg‘ utility)
"gpgProvider": "gpg",

// Disable signing of published repositories
"gpgDisableSign": false,

// Disable signature verification of remote repositories
"gpgDisableVerify": false,

// Publishing
//////////////

// Do not publish Contents files
"skipContentsPublishing": false,

// Do not create bz2 files
"skipBz2Publishing": false,

// Storage
///////////

// Filesystem publishing endpoints
//
// aptly defaults to publish to a single publish directory under ‘rootDir‘/public. For
// a more advanced publishing strategy, you can define one or more filesystem endpoints in the
// ‘FileSystemPublishEndpoints‘ list of the aptly configuration file. Each endpoint has a name
// and the following associated settings.
//
// In order to publish to such an endpoint, specify the endpoint as ‘filesystem:endpoint-name‘
// with ‘endpoint-name‘ as the name given in the aptly configuration file. For example:
//
// ‘aptly publish snapshot wheezy-main filesystem:test1:wheezy/daily‘
//
"FileSystemPublishEndpoints": {
// // Endpoint Name
// "test1": {
// // Directory for publishing
// "rootDir": "/opt/srv/aptly_public",

// // File Link Method for linking files from the internal pool to the published directory
// // * hardlink
// // * symlink
// // * copy
// "linkMethod": "hardlink",

// // File Copare Method for comparing existing links from the internal pool to the published directory
// // Only used when "linkMethod" is set to "copy"
// // * md5 (default: compare md5 sum)
// // * size (compare file size)
// "verifyMethod": "md5"
// }
},

// S3 Endpoint Support
//
// cloud storage). First, publishing
// endpoints should be described in aptly configuration file. Each endpoint has name
// and associated settings.
//
// In order to publish to S3, specify endpoint as ‘s3:endpoint-name:‘ before
// publishing prefix on the command line, e.g.:
//
// ‘aptly publish snapshot wheezy-main s3:test:‘
//
"S3PublishEndpoints": {
// // Endpoint Name
// "test": {

// // Amazon region for S3 bucket
// "region": "us-east-1",

// // Bucket name
// "bucket": "test-bucket",

// // Endpoint (optional)
// // When using S3-compatible cloud storage, specify hostname of service endpoint here,
// // region is ignored if endpoint is set (set region to some human-readable name)
// // (should be left blank for real Amazon S3)
// "endpoint": "",

// // Prefix (optional)
// // publishing under specified prefix in the bucket, defaults to
// // no prefix (bucket root)
// "prefix": "",

// // Default ACLs (optional)
// // assign ACL to published files (one of the canned ACLs in Amazon
// // terminology). Useful values: ‘private‘ (default), ‘public-read‘ (public
// // repository) or ‘none‘ (don’t set ACL). Public repositories could be consumed by ‘apt‘ using
// // HTTP endpoint (Amazon bucket should be configured for "website hosting"),
// // for private repositories special apt S3 transport is required.
// "acl": "private",

// // Credentials (optional)
// // Amazon credentials to access S3 bucket. If not supplied,
// // environment variables ‘AWS_ACCESS_KEY_ID‘ and ‘AWS_SECRET_ACCESS_KEY‘
// // are used.
// "awsAccessKeyID": "",
// "awsSecretAccessKey": "",

// // Storage Class (optional)
// // Amazon S3 storage class, defaults to ‘STANDARD‘. Other values
// // available: ‘REDUCED_REDUNDANCY‘ (lower price, lower redundancy)
// "storageClass": "STANDARD",

// // Encryption Method (optional)
// // Server-side encryption method, defaults to none. Currently
// // the only available encryption method is ‘AES256‘
// "encryptionMethod": "none",

// // Plus Workaround (optional)
// // Workaround misbehavior in apt and Amazon S3 for files with ‘+‘ in filename by
// // creating two copies of package files with ‘+‘ in filename: one original
// // and another one with spaces instead of plus signs
// // With ‘plusWorkaround‘ enabled, package files with plus sign
// // would be stored twice. aptly might not cleanup files with spaces when published
// // repository is dropped or updated (switched) to new version of repository (snapshot)
// "plusWorkaround": false,

// // Disable MultiDel (optional)
// // For S3-compatible cloud storages which do not support ‘MultiDel‘ S3 API,
// // enable this setting (file deletion would be slower with this setting enabled)
// "disableMultiDel": false,

// // ForceSig2 (optional)
// // Disable Signature V4 support, useful with non-AWS S3-compatible object stores
// // which do not support SigV4, shouldn’t be enabled for AWS
// "forceSigV2": false,

// // ForceVirtualHostedStyle (optional)
// // Disable path style visit, useful with non-AWS S3-compatible object stores
// // which only support virtual hosted style
// "forceVirtualHostedStyle": false,

// // Debug (optional)
// // Enables detailed request/response dump for each S3 operation
// "debug": false
// }
},

// Swift Endpoint Support
//
// aptly could be configured to publish repository directly to OpenStack Swift. First,
// publishing endpoints should be described in aptly configuration file. Each endpoint
// has name and associated settings.
//
// In order to publish to Swift, specify endpoint as ‘swift:endpoint-name:‘ before
// publishing prefix on the command line, e.g.:
//
// ‘aptly publish snapshot jessie-main swift:test:‘
//
"SwiftPublishEndpoints": {
// Endpoint Name
// "test": {

// // Container Name
// "container": "taylor1",

// // Prefix (optional)
// // Publish under specified prefix in the container, defaults to no prefix (container root)
// "prefix": "",

// // Credentials (optional)
// // OpenStack credentials to access Keystone. If not supplied, environment variables ‘OS_USERNAME‘ and ‘OS_PASSWORD‘ are used
// "osname": "",
// "password": "",

// // Tenant (optional)
// // OpenStack tenant name and id (in order to use v2 authentication)
// "tenant": "",
// "tenantid": "",

// // Auth URL (optional)
// // Full url of Keystone server (including port, and version).
// // Example ‘http://identity.example.com:5000/v2.0‘
// "authurl": ""
// }
},

// Azure Endpoint Support
//
// aptly can be configured to publish repositories directly to Microsoft Azure Blob
// Storage. First, publishing endpoints should be described in the aptly
// configuration file. Each endpoint has its name and associated settings.
"AzurePublishEndpoints": {
// // Endpoint Name
// "test": {

// // Container Name
// "container": "container1",

// // Prefix (optional)
// // Publishing under specified prefix in the container, defaults to no prefix (container root)
// "prefix": "",

// // Credentials
// // Azure storage account access key to access blob storage
// "accountName": "",
// "accountKey": "",

// // Endpoint URL
// // See: Azure documentation https://docs.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string
// // defaults to "https://<accountName>.blob.core.windows.net"
// "endpoint": ""
// }
},

// Package Pool
// Location for storing downloaded packages
// Type must be one of:
// * local
// * azure
"packagePoolStorage": {
// Local Pool
"type": "local",
// Local Pool Path
// empty path defaults to ‘rootDir‘/pool
"path": ""

// // Azure Azure Blob Storage Pool
// "type": "azure",
// "container": "pool1",

// // Prefix (optional)
// // Publishing under specified prefix in the container, defaults to no prefix (container root)
// "prefix": "",

// // Credentials
// // Azure storage account access key to access blob storage
// "accountName": "",
// "accountKey": "",

// // Endpoint URL
// // See: Azure documentation https://docs.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string
// // defaults to "https://<accountName>.blob.core.windows.net"
// "endpoint": ""
}

// End of config
}

PACKAGE QUERY

Some commands accept package queries to identify list of packages to process. Package query syntax almost matches reprepro query language. Query consists of the following simple terms:
direct package reference

reference to exaclty one package. Format is identical to the way aptly lists packages in show commands with -with-packages flag: name_version_arch , e.g.: libmysqlclient18_5.5.35-rel33.0-611.squeeze_amd64

dependency condition

syntax follows Debian dependency specification: package_name followed by optional version specification and architecture limit, e.g: mysql-client (>= 3.6) .

query against package fields

syntax is the same as for dependency conditions, but instead of package name field name is used, e.g: Priority (optional) .

Supported fields:

	○		all field names from Debian package control files are supported except for Filename , MD5sum , SHA1 , SHA256 , Size , Files , Checksums-SHA1 , Checksums-SHA256 .
	○		$Source is a name of source package (for binary packages)
	○		$SourceVersion is a version of source package
	○		$Architecture is Architecture for binary packages and source for source packages, when matching with equal ( = ) operator, package with any architecture matches all architectures but source .
	○		$Version has the same value as Version , but comparison operators use Debian version precedence rules
	○		$PackageType is deb for binary packages and source for source packages

Operators:

=

strict match, default operator is no operator is given

>= , <= , = , >> (strictly greater), << (strictly less)

lexicographical comparison for all fields and special rules when comparing package versions

	%		pattern matching, like shell patterns, supported special symbols are: [ˆ]?* , e.g.: $Version (% 3.5-*)
	˜		regular expression matching, e.g.: Name (˜ .*-dev)

Simple terms could be combined into more complex queries using operators , (and), | (or) and ! (not), parentheses () are used to change operator precedence. Match value could be enclosed in single ( ’ ) or double ( " ) quotes if required to resolve ambiguity, quotes inside quoted string should escaped with slash ( \ ).

Examples:
mysql-client

matches package mysql-client of any version and architecture (including source), also matches packages that Provide: mysql-client .

mysql-client (>= 3.6)

matches package mysql-client with version greater or equal to 3.6. Valid operators for version are: >= , <= , = , >> (strictly greater), << (strictly less).

mysql-client {i386}

matches package mysql-client on architecture i386 , architecture all matches all architectures but source.

mysql-client (>= 3.6) {i386}

version and architecture conditions combined.

libmysqlclient18_5.5.35-rel33.0-611.squeeze_amd64

direct package reference.

$Source (nginx)

all binary packages with nginx as source package.

!Name (˜ .*-dev), mail-transport, $Version (>= 3.5)

matches all packages that provide mail-transport with name that has no suffix -dev and with version greater or equal to 3.5 .

When specified on command line, query may have to be quoted according to shell rules, so that it stays single argument:

aptly repo import percona stable ’mysql-client (>= 3.6)’

PACKAGE DISPLAY FORMAT

Some aptly commands ( aptly mirror search , aptly package search , ...) support -format flag which allows to customize how search results are printed. Golang templates are used to specify display format, with all package stanza fields available to template. In addition to package stanza fields aptly provides:

Key

internal aptly package ID, unique for all packages in aptly (combination of ShortKey and FilesHash ).

FilesHash

hash that includes MD5 of all packages files.

ShortKey

package ID, which is unique in single list (mirror, repo, snapshot, ...), but not unique in whole aptly package collection.

For example, default aptly display format could be presented with the following template: {{.Package}}_{{.Version}}_{{.Architecture}} . To display package name with dependencies: {{.Package}} | {{.Depends}} . More information on Golang template syntax: http://godoc.org/text/template

GLOBAL OPTIONS

- architectures =

list of architectures to consider during (comma-separated), default to all available

- config =

location of configuration file (default locations in order: ˜/.aptly.conf, /usr/local/etc/aptly.conf, /etc/aptly.conf)

- db-open-attempts =10

number of attempts to open DB if it’s locked by other instance

- dep-follow-all-variants

when processing dependencies, follow a & b if dependency is ’a|b’

- dep-follow-recommends

when processing dependencies, follow Recommends

- dep-follow-source

when processing dependencies, follow from binary to Source packages

- dep-follow-suggests

when processing dependencies, follow Suggests

- dep-verbose-resolve

when processing dependencies, print detailed logs

- gpg-provider =

PGP implementation ("gpg", "gpg1", "gpg2" for external gpg or "internal" for Go internal implementation)

CREATE NEW MIRROR

aptly mirror create name archive url distribution [ component1 ...]

Creates mirror name of remote repository, aptly supports both regular and flat Debian repositories exported via HTTP and FTP. aptly would try download Release file from remote repository and verify its’ signature. Command line format resembles apt utlitily sources.list(5).

PPA urls could specified in short format:

$ aptly mirror create name ppa: user / project

Example:

$ aptly mirror create wheezy-main http://mirror.yandex.ru/debian/ wheezy main

Options:
- filter =

filter packages in mirror, use ’@file’ to read filter from file or ’@-’ for stdin

- filter-with-deps

when filtering, include dependencies of matching packages as well

- force-architectures

(only with architecture list) skip check that requested architectures are listed in Release file

- force-components

(only with component list) skip check that requested components are listed in Release file

- ignore-signatures

disable verification of Release file signatures

- keyring =

gpg keyring to use when verifying Release file (could be specified multiple times)

- max-tries =1

max download tries till process fails with download error

- with-installer

download additional not packaged installer files

- with-sources

download source packages in addition to binary packages

- with-udebs

download .udeb packages (Debian installer support)

LIST MIRRORS

aptly mirror list

List shows full list of remote repository mirrors.

Example:

$ aptly mirror list

Options:

	- json		display list in JSON format
	- raw		display list in machine-readable format

SHOW DETAILS ABOUT MIRROR

aptly mirror show name

Shows detailed information about the mirror.

Example:

$ aptly mirror show wheezy-main

Options:

- json

display record in JSON format

- with-packages

show detailed list of packages and versions stored in the mirror

DELETE MIRROR

aptly mirror drop name

Drop deletes information about remote repository mirror name . Package data is not deleted (since it could still be used by other mirrors or snapshots). If mirror is used as source to create a snapshot, aptly would refuse to delete such mirror, use flag -force to override.

Example:

$ aptly mirror drop wheezy-main

Options:

- force

force mirror deletion even if used by snapshots

UPDATE MIRROR

aptly mirror update name

Updates remote mirror (downloads package files and meta information). When mirror is created, this command should be run for the first time to fetch mirror contents. This command can be run multiple times to get updated repository contents. If interrupted, command can be safely restarted.

Example:

$ aptly mirror update wheezy-main

Options:
- download-limit =0

limit download speed (kbytes/sec)

- downloader =default

downloader to use (e.g. grab)

- force

force update mirror even if it is locked by another process

- ignore-checksums

ignore checksum mismatches while downloading package files and metadata

- ignore-signatures

disable verification of Release file signatures

- keyring =

gpg keyring to use when verifying Release file (could be specified multiple times)

- max-tries =1

max download tries till process fails with download error

- skip-existing-packages

do not check file existence for packages listed in the internal database of the mirror

RENAMES MIRROR

aptly mirror rename old-name new-name

Command changes name of the mirror.Mirror name should be unique.

Example:

$ aptly mirror rename wheezy-min wheezy-main

EDIT MIRROR SETTINGS

aptly mirror edit name

Command edit allows one to change settings of mirror: filters, list of architectures.

Example:

$ aptly mirror edit -filter=nginx -filter-with-deps some-mirror

Options:
- archive-url =

archive url is the root of archive

- filter =

filter packages in mirror, use ’@file’ to read filter from file or ’@-’ for stdin

- filter-with-deps

when filtering, include dependencies of matching packages as well

- ignore-signatures

disable verification of Release file signatures

- keyring =

gpg keyring to use when verifying Release file (could be specified multiple times)

- with-installer

download additional not packaged installer files

- with-sources

download source packages in addition to binary packages

- with-udebs

download .udeb packages (Debian installer support)

SEARCH MIRROR FOR PACKAGES MATCHING QUERY

aptly mirror search name [ package-query ]

Command search displays list of packages in mirror that match package query

If query is not specified, all the packages are displayed.

Example:

$ aptly mirror search wheezy-main ’$Architecture (i386), Name (% *-dev)’

Options:
- format =

custom format for result printing

- with-deps

include dependencies into search results

ADD PACKAGES TO LOCAL REPOSITORY

aptly repo add name (<package file.deb>|<directory>)...

Command adds packages to local repository from .deb, .udeb (binary packages) and .dsc (source packages) files. When importing from directory aptly would do recursive scan looking for all files matching .[u]deb or .dsc patterns. Every file discovered would be analyzed to extract metadata, package would then be created and added to the database. Files would be imported to internal package pool. For source packages, all required files are added automatically as well. Extra files for source package should be in the same directory as *.dsc file.

Example:

$ aptly repo add testing myapp-0.1.2.deb incoming/

Options:
- force-replace

when adding package that conflicts with existing package, remove existing package

- remove-files

remove files that have been imported successfully into repository

COPY PACKAGES BETWEEN LOCAL REPOSITORIES

aptly repo copy src-name dst-name package-query ...

Command copy copies packages matching package-query from local repo src-name to local repo dst-name .

Example:

$ aptly repo copy testing stable ’myapp (=0.1.12)’

Options:
- dry-run

don’t copy, just show what would be copied

- with-deps

follow dependencies when processing package-spec

CREATE LOCAL REPOSITORY

aptly repo create name [ from snapshot snapshot ]

Create local package repository. Repository would be empty when created, packages could be added from files, copied or moved from another local repository or imported from the mirror.

If local package repository is created from snapshot, repo initial contents are copied from snapsot contents.

Example:

$ aptly repo create testing

$ aptly repo create mysql35 from snapshot mysql-35-2017

Options:
- comment =

any text that would be used to described local repository

- component =main

default component when publishing

- distribution =

default distribution when publishing

- uploaders-file =

uploaders.json to be used when including .changes into this repository

DELETE LOCAL REPOSITORY

aptly repo drop name

Drop information about deletions from local repo. Package data is not deleted (since it could be still used by other mirrors or snapshots).

Example:

$ aptly repo drop local-repo

Options:

- force

force local repo deletion even if used by snapshots

EDIT PROPERTIES OF LOCAL REPOSITORY

aptly repo edit name

Command edit allows one to change metadata of local repository: comment, default distribution and component.

Example:

$ aptly repo edit -distribution=wheezy testing

Options:
- comment =

any text that would be used to described local repository

- component =

default component when publishing

- distribution =

default distribution when publishing

- uploaders-file =

uploaders.json to be used when including .changes into this repository

IMPORT PACKAGES FROM MIRROR TO LOCAL REPOSITORY

aptly repo import src-mirror dst-repo package-query ...

Command import looks up packages matching package-query in mirror src-mirror and copies them to local repo dst-repo .

Example:

$ aptly repo import wheezy-main testing nginx

Options:
- dry-run

don’t import, just show what would be imported

- with-deps

follow dependencies when processing package-spec

LIST LOCAL REPOSITORIES

aptly repo list

List command shows full list of local package repositories.

Example:

$ aptly repo list

Options:

	- json		display list in JSON format
	- raw		display list in machine-readable format

MOVE PACKAGES BETWEEN LOCAL REPOSITORIES

aptly repo move src-name dst-name package-query ...

Command move moves packages matching package-query from local repo src-name to local repo dst-name .

Use ’@file’ to read package queries from file or ’@-’ for stdin.

Example:

$ aptly repo move testing stable ’myapp (=0.1.12)’

Options:
- dry-run

don’t move, just show what would be moved

- with-deps

follow dependencies when processing package-spec

REMOVE PACKAGES FROM LOCAL REPOSITORY

aptly repo remove name package-query ...

Commands removes packages matching package-query from local repository name . If removed packages are not referenced by other repos or snapshots, they can be removed completely (including files) by running ’aptly db cleanup’.

Use ’@file’ to read package queries from file or ’@-’ for stdin.

Example:

$ aptly repo remove testing ’myapp (=0.1.12)’

Options:
- dry-run

don’t remove, just show what would be removed

SHOW DETAILS ABOUT LOCAL REPOSITORY

aptly repo show name

Show command shows full information about local package repository.

ex: $ aptly repo show testing

Options:

- json

display record in JSON format

- with-packages

show list of packages

RENAMES LOCAL REPOSITORY

aptly repo rename old-name new-name

Command changes name of the local repo. Local repo name should be unique.

Example:

$ aptly repo rename wheezy-min wheezy-main

SEARCH REPO FOR PACKAGES MATCHING QUERY

aptly repo search name [ package-query ]

Command search displays list of packages in local repository that match package query

If query is not specified, all the packages are displayed.

Example:

$ aptly repo search my-software ’$Architecture (i386), Name (% *-dev)’

Options:
- format =

custom format for result printing

- with-deps

include dependencies into search results

ADD PACKAGES TO LOCAL REPOSITORIES BASED ON .CHANGES FILES

aptly repo include (<file.changes>|<directory>)...

Command include looks for .changes files in list of arguments or specified directories. Each .changes file is verified, parsed, referenced files are put into separate temporary directory and added into local repository. Successfully imported files are removed by default.

Additionally uploads could be restricted with ’uploaders.json’ file. Rules in this file control uploads based on GPG key ID of .changes file signature and queries on .changes file fields.

Example:

$ aptly repo include -repo=foo-release incoming/

Options:
- accept-unsigned

accept unsigned .changes files

- force-replace

when adding package that conflicts with existing package, remove existing package

- ignore-signatures

disable verification of .changes file signature

- keyring =

gpg keyring to use when verifying Release file (could be specified multiple times)

- no-remove-files

don’t remove files that have been imported successfully into repository

- repo ={{.Distribution}}

which repo should files go to, defaults to Distribution field of .changes file

- uploaders-file =

path to uploaders.json file

CREATES SNAPSHOT OF MIRROR (LOCAL REPOSITORY) CONTENTS

aptly snapshot create name (from mirror mirror-name | from repo repo-name | empty)

Command create name from mirror makes persistent immutable snapshot of remote repository mirror. Snapshot could be published or further modified using merge, pull and other aptly features.

Command create name from repo makes persistent immutable snapshot of local repository. Snapshot could be processed as mirror snapshots, and mixed with snapshots of remote mirrors.

Command create name empty creates empty snapshot that could be used as a basis for snapshot pull operations, for example. As snapshots are immutable, creating one empty snapshot should be enough.

Example:

$ aptly snapshot create wheezy-main-today from mirror wheezy-main

LIST SNAPSHOTS

aptly snapshot list

Command list shows full list of snapshots created.

Example:

$ aptly snapshot list

Options:

	- json		display list in JSON format
	- raw		display list in machine-readable format

- sort =name

display list in ’name’ or creation ’time’ order

SHOWS DETAILS ABOUT SNAPSHOT

aptly snapshot show name

Command show displays full information about a snapshot.

Example:

$ aptly snapshot show wheezy-main

Options:

- json

display record in JSON format

- with-packages

show list of packages

VERIFY DEPENDENCIES IN SNAPSHOT

aptly snapshot verify name [ source ...]

Verify does dependency resolution in snapshot name , possibly using additional snapshots source as dependency sources. All unsatisfied dependencies are printed.

Example:

$ aptly snapshot verify wheezy-main wheezy-contrib wheezy-non-free

PULL PACKAGES FROM ANOTHER SNAPSHOT

aptly snapshot pull name source destination package-query ...

Command pull pulls new packages along with its’ dependencies to snapshot name from snapshot source . Pull can upgrade package version in name with versions from source following dependencies. New snapshot destination is created as a result of this process. Packages could be specified simply as ’package-name’ or as package queries.

Use ’@file’ syntax to read package queries from file and ’@-’ to read from stdin.

Example:

$ aptly snapshot pull wheezy-main wheezy-backports wheezy-new-xorg xorg-server-server

Options:
- all-matches

pull all the packages that satisfy the dependency version requirements

- dry-run

don’t create destination snapshot, just show what would be pulled

- no-deps

don’t process dependencies, just pull listed packages

- no-remove

don’t remove other package versions when pulling package

DIFFERENCE BETWEEN TWO SNAPSHOTS

aptly snapshot diff name-a name-b

Displays difference in packages between two snapshots. Snapshot is a list of packages, so difference between snapshots is a difference between package lists. Package could be either completely missing in one snapshot, or package is present in both snapshots with different versions.

Example:

$ aptly snapshot diff -only-matching wheezy-main wheezy-backports

Options:
- only-matching

display diff only for matching packages (don’t display missing packages)

MERGES SNAPSHOTS

aptly snapshot merge destination source [ source ...]

Merge command merges several source snapshots into one destination snapshot. Merge happens from left to right. By default, packages with the same name-architecture pair are replaced during merge (package from latest snapshot on the list wins). If run with only one source snapshot, merge copies source into destination .

Example:

$ aptly snapshot merge wheezy-w-backports wheezy-main wheezy-backports

Options:
- latest

use only the latest version of each package

- no-remove

don’t remove duplicate arch/name packages

DELETE SNAPSHOT

aptly snapshot drop name

Drop removes information about a snapshot. If snapshot is published, it can’t be dropped.

Example:

$ aptly snapshot drop wheezy-main

Options:

- force

remove snapshot even if it was used as source for other snapshots

RENAMES SNAPSHOT

aptly snapshot rename old-name new-name

Command changes name of the snapshot. Snapshot name should be unique.

Example:

$ aptly snapshot rename wheezy-min wheezy-main

SEARCH SNAPSHOT FOR PACKAGES MATCHING QUERY

aptly snapshot search name [ package-query ]

Command search displays list of packages in snapshot that match package query

If query is not specified, all the packages are displayed.

Use ’@file’ syntax to read package query from file and ’@-’ to read from stdin.

Example:

$ aptly snapshot search wheezy-main ’$Architecture (i386), Name (% *-dev)’

Options:
- format =

custom format for result printing

- with-deps

include dependencies into search results

FILTER PACKAGES IN SNAPSHOT PRODUCING ANOTHER SNAPSHOT

aptly snapshot filter source destination package-query ...

Command filter does filtering in snapshot source , producing another snapshot destination . Packages could be specified simply as ’package-name’ or as package queries.

Use ’@file’ syntax to read package queries from file and ’@-’ to read from stdin.

Example:

$ aptly snapshot filter wheezy-main wheezy-required ’Priority (required)’

Options:
- with-deps

include dependent packages as well

REMOVE PUBLISHED REPOSITORY

aptly publish drop distribution [[ endpoint :] prefix ]

Command removes whatever has been published under specified prefix , publishing endpoint and distribution name.

Example:

$ aptly publish drop wheezy

Options:
- force-drop

remove published repository even if some files could not be cleaned up

- skip-cleanup

don’t remove unreferenced files in prefix/component

LIST OF PUBLISHED REPOSITORIES

aptly publish list

Display list of currently published snapshots.

Example:

$ aptly publish list

Options:

	- json		display list in JSON format
	- raw		display list in machine-readable format

PUBLISH LOCAL REPOSITORY

aptly publish repo name [[ endpoint :] prefix ]

Command publishes current state of local repository ready to be consumed by apt tools. Published repostiories appear under rootDir/public directory. Valid GPG key is required for publishing.

Multiple component repository could be published by specifying several components split by commas via -component flag and multiple local repositories as the arguments:

aptly publish repo -component=main,contrib repo-main repo-contrib

It is not recommended to publish local repositories directly unless the repository is for testing purposes and changes happen frequently. For production usage please take snapshot of repository and publish it using publish snapshot command.

Example:

$ aptly publish repo testing

Options:
- acquire-by-hash

provide index files by hash

- batch

run GPG with detached tty

- butautomaticupgrades =

set value for ButAutomaticUpgrades field

- codename =

codename to publish (defaults to distribution)

- component =

component name to publish (for multi-component publishing, separate components with commas)

- distribution =

distribution name to publish

- force-overwrite

overwrite files in package pool in case of mismatch

- gpg-key =

GPG key ID to use when signing the release

- keyring =

GPG keyring to use (instead of default)

- label =

label to publish

- multi-dist

enable multiple packages with the same filename in different distributions

- notautomatic =

set value for NotAutomatic field

- origin =

origin name to publish

- passphrase =

GPG passphrase for the key (warning: could be insecure)

- passphrase-file =

GPG passphrase-file for the key (warning: could be insecure)

- secret-keyring =

GPG secret keyring to use (instead of default)

- skip-bz2

don’t generate bzipped indexes

- skip-contents

don’t generate Contents indexes

- skip-signing

don’t sign Release files with GPG

- suite =

suite to publish (defaults to distribution)

SHOWS DETAILS OF PUBLISHED REPOSITORY

aptly publish show distribution [[ endpoint :] prefix ]

Command show displays full information of a published repository.

Example:

$ aptly publish show wheezy

Options:

- json

display record in JSON format

PUBLISH SNAPSHOT

aptly publish snapshot name [[ endpoint :] prefix ]

Command publishes snapshot as Debian repository ready to be consumed by apt tools. Published repostiories appear under rootDir/public directory. Valid GPG key is required for publishing.

Multiple component repository could be published by specifying several components split by commas via -component flag and multiple snapshots as the arguments:

aptly publish snapshot -component=main,contrib snap-main snap-contrib

Example:

$ aptly publish snapshot wheezy-main

Options:
- acquire-by-hash

provide index files by hash

- batch

run GPG with detached tty

- butautomaticupgrades =

overwrite value for ButAutomaticUpgrades field

- codename =

codename to publish (defaults to distribution)

- component =

component name to publish (for multi-component publishing, separate components with commas)

- distribution =

distribution name to publish

- force-overwrite

overwrite files in package pool in case of mismatch

- gpg-key =

GPG key ID to use when signing the release

- keyring =

GPG keyring to use (instead of default)

- label =

label to publish

- multi-dist

enable multiple packages with the same filename in different distributions

- notautomatic =

overwrite value for NotAutomatic field

- origin =

overwrite origin name to publish

- passphrase =

GPG passphrase for the key (warning: could be insecure)

- passphrase-file =

GPG passphrase-file for the key (warning: could be insecure)

- secret-keyring =

GPG secret keyring to use (instead of default)

- skip-bz2

don’t generate bzipped indexes

- skip-contents

don’t generate Contents indexes

- skip-signing

don’t sign Release files with GPG

- suite =

suite to publish (defaults to distribution)

ADD SOURCE COMPONENTS TO A PUBLISHED REPO

aptly publish source add distribution source

The command adds components of a snapshot or local repository to be published.

This does not publish the changes directly, but rather schedules them for a subsequent ’aptly publish update’.

The flag -component is mandatory. Use a comma-separated list of components, if multiple components should be modified. The number of given components must be equal to the number of given sources, e.g.:

aptly publish source add -component=main,contrib wheezy wheezy-main wheezy-contrib

Example:

$ aptly publish source add -component=contrib wheezy ppa wheezy-contrib

This command assigns the snapshot wheezy-contrib to the component contrib and adds it to published repository revision of ppa/wheezy.

Options:
- component =

component names to add (for multi-component publishing, separate components with commas)

- prefix =.

publishing prefix in the form of [ endpoint :] prefix

DROP PENDING SOURCE COMPONENT CHANGES OF A PUBLISHED REPOSITORY

aptly publish source drop distribution

Remove all pending changes what would be applied with a subsequent ’aptly publish update’.

Example:

$ aptly publish source drop wheezy

Options:
- component =

component names to add (for multi-component publishing, separate components with commas)

- prefix =.

publishing prefix in the form of [ endpoint :] prefix

LISTS REVISION OF PUBLISHED REPOSITORY

aptly publish source list distribution

Command lists sources of a published repository.

Example:

$ aptly publish source list wheezy

Options:
- component =

component names to add (for multi-component publishing, separate components with commas)

- json

display record in JSON format

- prefix =.

publishing prefix in the form of [ endpoint :] prefix

REMOVE SOURCE COMPONENTS FROM A PUBLISHED REPO

aptly publish source remove distribution [[ endpoint :] prefix ] source

The command removes source components (snapshot / local repo) from a published repository.

This does not publish the changes directly, but rather schedules them for a subsequent ’aptly publish update’.

The flag -component is mandatory. Use a comma-separated list of components, if multiple components should be removed, e.g.:

Example:

$ aptly publish source remove -component=contrib,non-free wheezy filesystem:symlink:debian

Options:
- component =

component names to remove (for multi-component publishing, separate components with commas)

- prefix =.

publishing prefix in the form of [ endpoint :] prefix

REPLACE THE SOURCE COMPONENTS OF A PUBLISHED REPOSITORY

aptly publish source replace distribution source

The command replaces the source components of a snapshot or local repository to be published.

This does not publish the changes directly, but rather schedules them for a subsequent ’aptly publish update’.

The flag -component is mandatory. Use a comma-separated list of components, if multiple components should be modified. The number of given components must be equal to the number of given sources, e.g.:

aptly publish source replace -component=main,contrib wheezy wheezy-main wheezy-contrib

Example:

$ aptly publish source replace -component=contrib wheezy ppa wheezy-contrib

Options:
- component =

component names to add (for multi-component publishing, separate components with commas)

- prefix =.

publishing prefix in the form of [ endpoint :] prefix

UPDATE THE SOURCE COMPONENTS OF A PUBLISHED REPOSITORY

aptly publish source update distribution source

The command updates the source components of a snapshot or local repository to be published.

This does not publish the changes directly, but rather schedules them for a subsequent ’aptly publish update’.

The flag -component is mandatory. Use a comma-separated list of components, if multiple components should be modified. The number of given components must be equal to the number of given sources, e.g.:

aptly publish source update -component=main,contrib wheezy wheezy-main wheezy-contrib

Example:

$ aptly publish source update -component=contrib wheezy ppa wheezy-contrib

Options:
- component =

component names to add (for multi-component publishing, separate components with commas)

- prefix =.

publishing prefix in the form of [ endpoint :] prefix

UPDATE PUBLISHED REPOSITORY BY SWITCHING TO NEW SOURCE

aptly publish switch distribution [[ endpoint :] prefix ] new-source

Command switches in-place published snapshots with new source contents. All publishing parameters are preserved (architecture list, distribution, component).

For multiple component repositories, flag -component should be given with list of components to update. Corresponding sources should be given in the same order, e.g.:

aptly publish switch -component=main,contrib wheezy wh-main wh-contrib

Example:

$ aptly publish switch wheezy ppa wheezy-7.5

This command would switch published repository (with one component) named ppa/wheezy (prefix ppa, dsitribution wheezy to new snapshot wheezy-7.5).

Options:

- batch

run GPG with detached tty

- component =

component names to update (for multi-component publishing, separate components with commas)

- force-overwrite

overwrite files in package pool in case of mismatch

- gpg-key =

GPG key ID to use when signing the release

- keyring =

GPG keyring to use (instead of default)

- multi-dist

enable multiple packages with the same filename in different distributions

- passphrase =

GPG passphrase for the key (warning: could be insecure)

- passphrase-file =

GPG passphrase-file for the key (warning: could be insecure)

- secret-keyring =

GPG secret keyring to use (instead of default)

- skip-bz2

don’t generate bzipped indexes

- skip-cleanup

don’t remove unreferenced files in prefix/component

- skip-contents

don’t generate Contents indexes

- skip-signing

don’t sign Release files with GPG

UPDATE PUBLISHED REPOSITORY

aptly publish update distribution [[ endpoint :] prefix ]

The command updates updates a published repository after applying pending changes to the sources.

For published local repositories:

* update to match local repository contents

For published snapshots:

* switch components to new snapshot

The update happens in-place with minimum possible downtime for published repository.

For multiple component published repositories, all local repositories are updated.

Example:

$ aptly publish update wheezy ppa

Options:

- batch

run GPG with detached tty

- force-overwrite

overwrite files in package pool in case of mismatch

- gpg-key =

GPG key ID to use when signing the release

- keyring =

GPG keyring to use (instead of default)

- multi-dist

enable multiple packages with the same filename in different distributions

- passphrase =

GPG passphrase for the key (warning: could be insecure)

- passphrase-file =

GPG passphrase-file for the key (warning: could be insecure)

- secret-keyring =

GPG secret keyring to use (instead of default)

- skip-bz2

don’t generate bzipped indexes

- skip-cleanup

don’t remove unreferenced files in prefix/component

- skip-contents

don’t generate Contents indexes

- skip-signing

don’t sign Release files with GPG

SEARCH FOR PACKAGES MATCHING QUERY

aptly package search [ package-query ]

Command search displays list of packages in whole DB that match package query.

Use ’@file’ to read query from file or ’@-’ for stdin. If query is not specified, all the packages are displayed.

Example:

$ aptly package search ’$Architecture (i386), Name (% *-dev)’

Options:
- format =

custom format for result printing

SHOW DETAILS ABOUT PACKAGES MATCHING QUERY

aptly package show package-query

Command shows displays detailed meta-information about packages matching query. Information from Debian control file is displayed. Optionally information about package files and inclusion into mirrors/snapshots/local repos is shown.

Use ’@file’ to read query from file or ’@-’ for stdin.

Example:

$ aptly package show ’nginx-light_1.2.1-2.2+wheezy2_i386’

Options:
- with-files

display information about files from package pool

- with-references

display information about mirrors, snapshots and local repos referencing this package

CLEANUP DB AND PACKAGE POOL

aptly db cleanup

Database cleanup removes information about unreferenced packages and removes files in the package pool that aren’t used by packages anymore

Example:

$ aptly db cleanup

Options:
- dry-run

don’t delete anything

- verbose

be verbose when loading objects/removing them

RECOVER DB AFTER CRASH

aptly db recover

Database recover does its’ best to recover the database after a crash. It is recommended to backup the DB before running recover.

Example:

$ aptly db recover

HTTP SERVE PUBLISHED REPOSITORIES

aptly serve

Command serve starts embedded HTTP server (not suitable for real production usage) to serve contents of public/ subdirectory of aptly’s root that contains published repositories.

Example:

$ aptly serve -listen=:8080

Options:
- listen =:8080

host:port for HTTP listening

START API HTTP SERVICE

aptly api serve

Start HTTP server with aptly REST API. The server can listen to either a port or Unix domain socket. When using a socket, Aptly will fully manage the socket file. This command also supports taking over from a systemd file descriptors to enable systemd socket activation.

Example:

$ aptly api serve -listen=:8080 $ aptly api serve -listen=unix:///tmp/aptly.sock

Options:
- listen =:8080

host:port for HTTP listening or unix://path to listen on a Unix domain socket

- no-lock

don’t lock the database

RENDER GRAPH OF RELATIONSHIPS

aptly graph

Command graph displays relationship between mirrors, local repositories, snapshots and published repositories using graphviz package to render graph as an image.

Example:

$ aptly graph

Options:
- format =png

render graph to specified format (png, svg, pdf, etc.)

- layout =horizontal

create a more ’vertical’ or a more ’horizontal’ graph layout

- output =

specify output filename, default is to open result in viewer

SHOW CURRENT APTLY’S CONFIG

aptly config show

Command show displays the current aptly configuration.

Example:

$ aptly config show

Options:

- yaml

show yaml config

RUN APTLY TASKS

aptly task run (-filename= filename | commands ...)

Command helps organise multiple aptly commands in one single aptly task, running as single thread.

Example:

$ aptly task run
> repo create local
> repo add local pkg1
> publish repo local
> serve
>

Options:
- filename =

specifies the filename that contains the commands to run

SHOW CURRENT APTLY’S CONFIG

aptly config show

Command show displays the current aptly configuration.

Example:

$ aptly config show

Options:

- yaml

show yaml config

ENVIRONMENT

If environment variable HTTP_PROXY is set aptly would use its value to proxy all HTTP requests.

RETURN VALUES

aptly exists with:

	0		success
	1		general failure
	2		command parse failure

AUTHORS

List of contributors, in chronological order:

	○		Andrey Smirnov (https://github.com/smira)
	○		Sebastien Binet (https://github.com/sbinet)
	○		Ryan Uber (https://github.com/ryanuber)
	○		Simon Aquino (https://github.com/queeno)
	○		Vincent Batoufflet (https://github.com/vbatoufflet)
	○		Ivan Kurnosov (https://github.com/zerkms)
	○		Dmitrii Kashin (https://github.com/freehck)
	○		Chris Read (https://github.com/cread)
	○		Rohan Garg (https://github.com/shadeslayer)
	○		Russ Allbery (https://github.com/rra)
	○		Sylvain Baubeau (https://github.com/lebauce)
	○		Andrea Bernardo Ciddio (https://github.com/bcandrea)
	○		Michael Koval (https://github.com/mkoval)
	○		Alexander Guy (https://github.com/alexanderguy)
	○		Sebastien Badia (https://github.com/sbadia)
	○		Szymon Sobik (https://github.com/sobczyk)
	○		Paul Krohn (https://github.com/paul-krohn)
	○		Vincent Bernat (https://github.com/vincentbernat)
	○		x539 (https://github.com/x539)
	○		Phil Frost (https://github.com/bitglue)
	○		Benoit Foucher (https://github.com/bentoi)
	○		Geoffrey Thomas (https://github.com/geofft)
	○		Oliver Sauder (https://github.com/sliverc)
	○		Harald Sitter (https://github.com/apachelogger)
	○		Johannes Layher (https://github.com/jola5)
	○		Charles Hsu (https://github.com/charz)
	○		Clemens Rabe (https://github.com/seeraven)
	○		TJ Merritt (https://github.com/tjmerritt)
	○		Matt Martyn (https://github.com/MMartyn)
	○		Ludovico Cavedon (https://github.com/cavedon)
	○		Petr Jediny (https://github.com/pjediny)
	○		Maximilian Stein (https://github.com/steinymity)
	○		Strajan Sebastian (https://github.com/strajansebastian)
	○		Artem Smirnov (https://github.com/urpylka)
	○		William Manley (https://github.com/wmanley)
	○		Shengjing Zhu (https://github.com/zhsj)
	○		Nabil Bendafi (https://github.com/nabilbendafi)
	○		Raphael Medaer (https://github.com/rmedaer)
	○		Raul Benencia (https://github.com/rul)
	○		Don Kuntz (https://github.com/dkuntz2)
	○		Joshua Colson (https://github.com/freakinhippie)
	○		Andre Roth (https://github.com/neolynx)
	○		Lorenzo Bolla (https://github.com/lbolla)
	○		Benj Fassbind (https://github.com/randombenj)
	○		Markus Muellner (https://github.com/mmianl)
	○		Chuan Liu (https://github.com/chuan)
	○		Samuel Mutel (https://github.com/smutel)
	○		Russell Greene (https://github.com/russelltg)
	○		Wade Simmons (https://github.com/wadey)
	○		Steven Stone (https://github.com/smstone)
	○		Josh Bayfield (https://github.com/jbayfield)
	○		Boxjan (https://github.com/boxjan)
	○		Mauro Regli (https://github.com/reglim)
	○		Alexander Zubarev (https://github.com/strike)
	○		Nicolas Dostert (https://github.com/acdn-ndostert)
	○		Ryan Gonzalez (https://github.com/refi64)
	○		Paul Cacheux (https://github.com/paulcacheux)
	○		Nic Waller (https://github.com/sf-nwaller)
	○		iofq (https://github.com/iofq)
	○		Noa Resare (https://github.com/nresare)
	○		Ramon N.Rodriguez (https://github.com/runitonmetal)
	○		Golf Hu (https://github.com/hudeng-go)
	○		Cookie Fei (https://github.com/wuhuang26)
	○		Andrey Loukhnov (https://github.com/aol-nnov)
	○		Christoph Fiehe (https://github.com/cfiehe)
	○		Blake Kostner (https://github.com/btkostner)
	○		Leigh London (https://github.com/leighlondon)
	○		Gordian Schoenherr (https://github.com/schoenherrg)

---