Compare commits


Author SHA1 Message Date
  Mark Hindley 1e966daf93 Unify use of `codename` to refer to suites names. 1 year ago
  Mark Hindley ef3d2d5ea7 Unify style referencing url placeholder elements. 1 year ago
  Mark Hindley d9824816f0 Update url scheme to https. 1 year ago
  Mark Hindley 0658195692 Releasebot runs every minute. Further rewrites for clarity. 1 year ago
  LeePen 631609167e Merge pull request 'update link and fix "missing" examples' (#1) from bgstack15/documentation:wip/new-packaging-guide into wip/new-packaging-guide 1 year ago
  B Stack 6465096bcb update link and fix "missing" examples 1 year ago
  Mark Hindley b9a6880cc2 Minor rewording for clarity. 1 year ago
  Mark Hindley 84149d134a Reword branch name instructions. 1 year ago
  Mark Hindley 8d221cb9f5 Update for Gitea migration, releasebot update and Jenkins unified pipeline. 1 year ago
  Mark Hindley 433d3e1ef3 Add paragraph about autopkgtests. 1 year ago
  Mark Hindley c103f807bc Fix relative links. 1 year ago
  Mark Hindley 00ba8bb5b9 Document the necessity to remove Built-Using fields. 1 year ago
  Mark Hindley c153bbe9a7 Cleanup formatting of code blocks. 1 year ago
  Mark Hindley 51ab533fdd Refine and reword. 1 year ago
  Mark Hindley 35be8a67ca Fix typo. 1 year ago
  Mark Hindley ea74067a92 Add information about updating chroots and pbuilder hooks. 1 year ago
  Mark Hindley 6a514f93ef Update with general information. 1 year ago
  Mark Hindley baa10159cb Add autoclose of bug reports. 1 year ago
  Mark Hindley 6a10b19147 Fix typo. 1 year ago
  Mark Hindley 4172244482 Add use of devuan-lintian-profile. 1 year ago
  Mark Hindley e7f38043ed Add lintian. 1 year ago
  Mark Hindley 9d6013eaa6 Correct branch to suites/*. 1 year ago
  Mark Hindley d71d2df354 Refine and expand details. 1 year ago
  Mark Hindley a444c6da8b Basic factual updates to JenkinsAutobuild. 1 year ago
  Mark Hindley a7eaa727e8 Remove home.markdown and use .md rather than .markdown. 1 year ago
  Mark Hindley 251fd82fe2 Add mirror to gbp buildpackage create. 1 year ago
  Mark Hindley 0eb9322639 First draft of new packaging guide. 1 year ago
  Mark Hindley c6b1b6d9c5 Delete obsolete GitPackages.markdown. 1 year ago
6 changed files with 302 additions and 169 deletions
Split View
  1. +0
  2. +0
  3. +43
  4. +240
  5. +19
  6. +0

+ 0
- 98
maintainers/GitPackages.markdown View File

@@ -1,98 +0,0 @@
# Git structure for devuan packages

* [Introduction](#introduction)
* [Packages coming from debian](#packages-coming-from-debian)
* [debian packages using pristine-tar format for origin upstream](#debian-packages-using-pristine-tar-format-for-origin-upstream)
* [debian packages with sources as git branches](#debian-packages-with-sources-as-git-branches)
* [Packages coming from third party upstream](#packages-coming-directly-from-third-party-upstream)
* [packages using pristine-tar format for origin upstream](#packages-using-pristine-tar-format-for-origin-upstream)
* [packages with sources as git branches](#packages-with-sources-as-git-branches)
* [Devuan native packages](#devuan-native-packages)
* [Autobuild of devuan packages](#autobuild-of-devuan-packages)

## Introduction
Once granted access to our gitlab, you can start hosting sources for devuan packages. Packages can be maintained both in a gitlab group for collaborative maintainence, or in your user namespace if you prefer, at least initially, and then moved to a group only when the package is ready to be pushed in our autobuild infrastructure and then in the official devuan repository once accepted for inclusion.

I assume you already know how to mark the package you are working on as maintained on the issues of the [Devuan Maintainers Project](/devuan/devuan-maintainers/)

The git repository for devuan packages follows a standardized schema that depends on where the original upstream source comes from and on the tools you prefer to use.

In any case, there are some conventions about branches and tags names to be used on devuan git repos:

* branches:
* **master**: the main developement branch. It should be used for package developement efforts, and it's not assured it will compile cleanly as it is a work in progress. master is synced with the "next unstable"
* **suites/experimental**: complete source tree for package [autobuild](#autobuild-of-devuan-packages) in experimental suite
* **suites/unstable**: complete source tree for package [autobuild](#autobuild-of-devuan-packages) in unstable suite
* **suites/[codename]**: complete source tree for package [autobuild](#autobuild-of-devuan-packages) in [codename], both for stable and testing
* **suites/[codename]-updates**: complete source tree for package [autobuild](#autobuild-of-devuan-packages) in [codename] after [codename] is released as stable and there are important updates
* **suites/[codename]-proposed-updates**: complete source tree for package [autobuild](#autobuild-of-devuan-packages) in [codename] after is released as stable and there are important updates not yet accepted
* **suites/[codename]-backports**: complete source tree for backports to [codename] after is released as stable
* **pristine-tar**: only for pristine-tar diff files is used
* **upstream/[version]**: complete source tree of original source package of [version] from upstream
* **debian/[debian_version]**: complete source tree of original source package of [debian_version] from debian
* tags
* **upstream/[version]**: tagged upstream version

Not all branches/tags are needed for every package, it depends, for example, if you use pristine-tar for upstream source tarball re-generation, or if the package source is coming from debian or it's native.
The mandatory branches are master and suites/*, the others will vary package from package.

Any other branch can be used for developement purpose as you prefer.

## Packages coming from debian

As we claim to be debian 1:1 compatible at least for jessie (devuan 1.0 - debian 8), we will try to maintain 1:1 version match with debian packages.

In future versions of devuan maybe 1:1 compatibility will be broken, but it's better to try to maintain it as long as we can to allow for easy migration of debian users to devuan.

For those reasons, many of our packages that are also in debian and that can be easily derived from it without major modifications will be derived directly from debian sources instead of upstream sources.

It's up to the devuan maintainer to monitor debian package versions and to maintain our packages in sync when they are updated on debian, a must for devuan/debian jessie, optional but strongly suggested for testing and unstable too.

All debian packages will have in common, indipendently from the method used to import sources, those branches:

* **master** the main developement branch, where the dirty work will be done, with the version of package equivalent to the most recent one present in other branches ( experimental if exists, or unstable )
* **suites/experimental** optional but suggested for package testing before to push it in unstable
* **suites/unstable** unstable package in devuan
* **suites/[suitename]** unstable package in [suitename]
* **suites/[suitename]-[updates|proposed-updates|backports]** optional only if they are needed
* **debian/[version]** at least 1 branch for every suite of debian ( stable/testing/unstable ) of equivalent versions
The first step for push debian package sources in Devuan repository is to get source packages from debian.

At the moment i'm writing, for Devuan there is no equivalent of "testing" in debian, as jessie in debian is testing, so as a starting point we will update jessie packages to both our "stable" aka jessie and to our "testing" aka ascii.

### debian packages using pristine-tar format for origin upstream

work in progress...

### debian packages with sources as git branches

work in progress...

## Packages coming directly from third party upstream

Some packages in devuan are not in debian or there is a need to re-package them from scratch cause debian version is too patched and/or badly patched for devuan inclusion without major modifications.

Those packages will have origin upstream sources coming directly from original upstream instead of debian sources. In case the same package is present in debian, it's suggested to maintain the same package name as debian has, and also it is strongly suggested, but not mandatory, to try to have the same version in devuan that debian has.

### packages using pristine-tar format for origin upstream

work in progress...

### packages with sources as git branches

work in progress...

## Devuan native packages

There are packages born in devuan for devuan, or born in devuan for wide usage. Those packages don't have an external upstream as their source origins are in the devuan git repositories. An example of those packages are loginkit, or devuan-baseconf. For those packages upstream branching isn't needed, nor is pristine-tar support, and they usually just use upstream tagging to create/re-create source tarballs.

work in progress...

## Autobuild of Devuan packages

work in progress...

[Jenkins autobuild](JenkinsAutobuild)

+ 0
- 29
maintainers/JenkinsAutobuild.markdown View File

@@ -1,29 +0,0 @@
# Jenkins Autobuild infrastructure in Devuan

Autobuild in devuan works as easy as to open an issue.

There is a little python bot, devuan-releasebot, that every 5 mins in a cron list all issues assigned to him and then, parsing labels and checking permissions, start a jenkins job to build the package and to push it in the repository.

## Requisites to start a build

Before to start a build with the autobuilder, you need to be sure to match some pre-requisites:

* having a buildable package source in devuan gitlab, with at least a branch names suites/<something> where <something> is the name of the suite to build ( at the moment i write this doc, jessie, ascii, unstable and experimental are accepted suites name).
* having at least master or owner access to the repository on gitlab for the package to be built
* the package should be already configured in jenkins ( ask the release team for that )
* having labels for the suites name in the gitlab project issues
* add the "autobuild" member to the project or group, "guest" access is enough, so you can assign an issue to him.

## How to start a build

If you have all requisites to start a build, you can start it as easy as to open an issue with title "build" on the project you want to build, assign the issue to "autobuild" gitlab member, and then add labels with the name of the suite you want to build to.

At the first run of the releasebot ( every 5 minutes ) it will comment the issue with infos regarding if the build is queued or if there is any error in the build request, and then it will close the issue.

You can then look at jenkins (, no login needed ) to see if your package is being built and pushed i the repository without errors.

## which packages are already configured i jenkins?

You can see a list of packages already configured in [jenkins source jobs](


+ 43
- 0
maintainers/ View File

@@ -0,0 +1,43 @@
# Jenkins Autobuild infrastructure in Devuan

Package builds in Devuan can be triggered by opening an
[Gitea]( issue.

A python script, [releasebot](, runs
every minute to scan for relevant issues. Having parsed labels and checked
permissions, it triggers the Jenkins job to build the package and deploy it to
the repository.

## Requirements to Trigger a Build

Before to start a build with the autobuilder, ensure you:

* have a tested, buildable package source in`<package>`, with a branch named
suites/`<codename>` where `<codename>` is the name of the suite to
build. Maintainers have permissions to build for unstable or testing.
Builds for released suites are restricted to administrators.
* are a collaborator on the package or a member of the [Gitea packages

NB. There is no longer a requirement to set up a specific Jenkins build job for
each individual package or configure build architectures.

## Triggering a Build

Once the prerequisites are satisfied, trigger a build by creating a new issue
against the package you wish to build with the title "build". Assign the issue
to "releasebot", and add label(s) with the name of the suite(s) for which you
want to build.

When it runs, releasebot will add comments to the issue regarding its actions
and then it will close the issue.

## Jenkins Pipeline

All Devuan packages are now built through a [common
pipeline]( (no login
needed) where you can follow the progress of your build.

The Jenkins Pipeline also sends notifications to the #devuan-ci channel on

+ 240
- 0
maintainers/ View File

@@ -0,0 +1,240 @@
# Packaging Guide for Devuan

## Introduction

This file documents Devuan's packaging infrastructure, guidelines and typical

Devuan is a derivative of Debian and much of Debian's documentation also
provides useful and relevant resources. In particular, the following are good
starting points:-


Devuan's source code is maintained in [git](, builds are
performed using [jenkins](, package repositories are
maintained with [dak]( and
those repositories are merged with Debian's to produce the distribution by

The majority of Devuan's packages are used directly from Debian with no
recompilation. Only packages that require modification are forked and rebuilt.

Packaging help can be found by asking on the #devuan-dev channel on

## Infrastructure

Devuan's source code is managed in a git repository (migrated from GitLab to
Gitea as of June 2020). The server is accessed at Archived historical GitLab repositories are available at

Users can create their own accounts to work on packages and create merge
requests. Official Devuan packages reside in the [devuan
organisation]( which provides the source
for Jenkins when builds are triggered.

If a user has sufficient permissions, builds can be triggered by opening a new
issue against the relevant devuan/`<source_package>` with the title
'build' and assigning it to releasebot. Further details can be found in

## Package Categories

There are four categories of packages in Devuan:-

1. Devuan only, not present in Debian.
2. Forked from Debian and modified.
3. Present in Debian but Devuan is the packaging upstream (currently only
elogind and eudev).
4. Used directly from Debian unchanged.

Packages in the last category will usually not be present in Devuan's git or
jenkins. However, packages can change category over time and so remnants of
previous incarnations may remain.

## Git

1. Clone a local copy of the relevant repository from
2. Add Debian's SCM as another remote. The URL can be found through [Debian
Package Tracker]( This is optional, but makes
merging much easier and is encouraged.
3. Create a new branch from your chosen starting point. This is usually the
version in Debian unstable. rmadison(1) from the devscripts package is a
convenient way of determining current Debian versions.

Usually packages are initially built for unstable or experimental so the
branch should be named suites/unstable or suites/experimental accordingly.
Sometimes packages are built to update suites that have already been
released. In that case the branch will be suites/`<codename>`-proposed where
`<codename>` is the release suite (jessie, ascii, beowulf, chimaera,

Once the branch is created and checked-out, add ```debian-branch =
suites/unstable``` (or whatever codename is appropriate) to the file
debian/gbp.conf. Create the file if necessary.

## Build Environment

The jenkins build pipeline uses git-buildpackage, pbuilder and cowbuilder. This
ensures more flexible and reproducible builds in a cleaner environment than
other build approaches. To avoid unexpected build failures in jenkins, you
should replicate this approach when testing. This approach also means that you
can build for suites, architectures and configurations that are incompatible
with your host sytem without conflicts.

To setup a local build environment

1. Install the required packages.

```apt install git-buildpackage pbuilder cowbuilder```

Some packages may require other debhelper modules to be installed (e.g.
dh-golang). If these are required builds will fail and the build log will
explicitly detail what is required.

2. Create a cowbuilder chroot.

There are many ways to do this. One of the simplest is to run

```gbp buildpackage --git-pbuilder --git-dist=ceres create --mirror ```

from within the git repository.

## Packaging Conventions

### debian/control

- Update Maintainers and Uploaders appropriately.
- Ensure that the Vcs-* fields contain the official Devuan URL
- Add ```Origin: Devuan``` to the source stanza.
- Remove any ```Built-Using:``` field.

As the Devuan archive (managed by DAK) only contains forked packages, Built-Using
dependencies are not necessarily satisfied.

### debian/gbp.conf

This file is useful for setting defaults for git-buildpackage. See gbp.conf(5).

Besides ```debian-branch``` already mentioned above, particularly useful settings include:-

- upstream-tag=upstream/v%(version)s
- debian-tag = devuan/%(version)s
- pristine-tar=False

Note that Devuan avoids the use of pristine-tar wherever possible as it fills
the repository with binary blobs. If Debian's package repository has a
pristine-tar branch you will need to prohibit git-buildpackage from using it.

## Packaging Workflow

1. Review bug reports at and also any issues that might
have been opened at`<source_package>`
and plan to address/incorporate fixes as required.

For any bugreports that you close, add (Closes: #<bugnumber>) at the end of
the debian/changelog line. This will automatically close the bug when the
package is built and enters the archive.

2. Make the changes required to the source code.

When doing this, remember that for non-native packages any changes outside
the debian/ directory are required to be implemented as quilt patches in
debian/patches/. This restriction does not apply to native packages.

3. Update debian/changelog.

The general convention for package numbering is to use the Debian version
with +devuanN appended (where N is an incremental integer).

4. Local build.

```gbp buildpackage --git-pbuilder --git-dist=ceres```

5. Lintian

Install devuan-lintian-profile.

```lintian *.changes```

6. Local install.

7. Repeat from 2 until you are finished.

8. Tag the release.

If you are working on a new package use the format
devuan/`<version>`. However, if there is already a convention in use that
particular package you might prefer to continue with the existing one.

9. Publish.

Push your branch and the tag to If you are working on a
non-native package you should also push the upstream tag.

10. Merge.

Create a merge request to or contact
a developer with access to review and merge your changes.

11. Build for release.

Details of triggering the Jenkins Build Pipeline can be found in

## Tips

### Updating Build Chroots

Cowbuilder chroots will need updating periodically, more often for the testing
and unstable distributions where packages change frequently. The indication that
this is required is usually build failures with 404 errors for build
dependencies, for example:

E: Failed to fetch
404 Not Found [IP: 80]

There are many ways of updating the chroots. The easiest is by running

```gbp buildpackage --git-pbuilder --git-dist=<distribution> update```

from the root of the git repository.

You may also find a pbuilder hook useful.

1. Configure a hook dir in ~/.pbuilderrc. For example:


2. Add a executable script in that directory to update the chroot package lists at the
beginning of the build:

The file should be ~/.pbuilder/hooks/D05apt-update


apt update

For further information see pbuilder(8).

### Autopkgtests

By default the jenkins builders run autopkgtests on amd64 architecture. To
ensure that the tests will not cause unexpected build failures, it is worth
including them in your build environment. This can be done by adding a symlink
from /usr/share/doc/pbuilder/examples/B20autopkgtest to the pbuilder hook
directory configured in ~/.pbuilderrc.

+ 19
- 19
maintainers/ View File

@@ -1,24 +1,24 @@
# Devuan Maintainers Repository
# Contributing to Devuan

This project was created to circumvent a limitation of Gitlab groups
that can't receive issues directly, and thus address the need for
volunteers to step up and take responsibility for the maintenance of a
Devuan package.
There is no formal procedure to become a Devuan contributor. A good starting
place is to join the conversations on the #devuan-dev channel at and subscribe to the [Devuan Developers
list]( The
community will be interested to hear your ideas, experience and the ways in
which you wish to contribute. There is also a weekly meeting (currently Thursday
at 2030UTC) which is open to everybody.

## Becoming a Package Maintainer
# Becoming a Package Maintainer

Currently the packages are listed in the [devuan-packages](/wikis/../../../../groups/devuan-packages) group. If you're interested in maintaining a package, simply [open an issue](../../issues/new) with the package name. Everything is manual, so bear it in mind if you experience delays. Once your application has been accepted, you will be granted master privilege for the package.
Sources for current (and historical) packages are kept in the
[devuan-packages]( group of our [git
repository]( If you are looking to adopt a package,
those that are maintained by
generally have no specific maintainer and could be taken over.

Also, take care to read:
* Guide for setting up [git repos in devuan](/wikis/../../wikis/GitPackages)
* Guide for [jenkins autobuild infrastructure in devuan](/wikis/../../wikis/JenkinsAutobuild)
# [Adopt a package](/wikis/../../wikis/home)

You can use the package's issue to help the community keeping track of the state of maintenance of this package. Especially, you can use labels to ease transitioning maintainers, etc. Here are a few shortcuts:
Prospective Package Maintainers will also find the following useful:

+ [Maintained Packages](/issues/../../issues?label_name=maintained)
+ [Orphan Packages](/issues/../../issues?label_name=orphan)
+ [Maintainer wanted](/issues/../../issues?label_name=maintainer+wanted)

If a package is missing, you may [create an issue](/issues/../../issues/new) for it.
* [Devuan Packaging Guide](./
* [Jenkins Autobuild Infrastructure](./

+ 0
- 23
maintainers/home.markdown View File

@@ -1,23 +0,0 @@
Devuan packages can be "adopted": **missing** and **claimed** packages are indicated below.

## Adopting a Package

A **missing** package is up for adoption: adopting a package means you're responsible for maintaining it up-to-date. You're also responsible for the relation with upstream.

Each package should have an issue open in its name in the [devuan-maintainers issue tracker](/devuan/devuan-maintainers/issues). The packages themselves belong to the [packages-base](/groups/packages-base) group.

1. Verify that the package was not already adopted, or is pending adoption. If an issue already exists, talk with the people there.
2. Claim a **missing** package: add or change the corresponding line in the table, and put your Gitlab username.
3. Please [open an issue named after the package](/devuan/devuan-maintainers/issues/new) to adopt it.

| Package Name | State | Maintainer |
| sample-missing-package | missing | |
| sample-claimed-package | claimed | @hellekin |

Note: once you have a package project in [packages-base](/groups/packages-base), you can update the state to **maintained** and link the package name to its Gitlab page.

Related issues: devuan/devuan-project#10 and devuan/devuan-project#11.

* Guide for setting up [git repos in devuan](GitPackages)
* Guide for [jenkins autobuild infrastructure in devuan](JenkinsAutobuild)