About Debusine
Debusine's goal is to be an integrated solution to build, distribute and maintain a Debian-based distribution.
Debusine is already a modern cloud-powered Continuous Integration (CI) platform to run many packaging and distribution related workflows for the Debian ecosystem.
As part of Freexian's mission, we are trying to build Debian's next generation infrastructure, providing a more integrated experience to Debian developers while enabling many new features that are entirely out of reach with the current infrastructure.
Many of Debusine's intended features are still in development, but it is already usable in a number of situations. Freexian is maintaining a Debusine instance at debusine.debian.net which can be used by all Debian developers using Salsa authentication.
With debusine.debian.net, it is already very easy for Debian contributors to use all the QA tools that Debian provides prior to any upload. But we will go further than that with distribution-wide experiments, custom package repositories, and custom workflows with advanced package reviews.
We invite you to try it out for yourself. This page is a tutorial to guide you through the various workflows that are usable and available for Debian developers on debusine.debian.net.
Contents
Authenticating to debusine.debian.net
Install the debusine-client package, which is in bookworm-backports and trixie (and newer). The rest of these instructions assume at least version 0.11.1~bpo12+1.
Run debusine --server=debian setup, then type "save" and press Enter. Follow its instructions to complete the process, which will create ~/.config/debusine/client/config.ini.
Scopes and workspaces
Debusine instances are organized using scopes and workspaces. On debusine.debian.net, we have a "debian" scope to group together everything related to Debian (we may have scopes for other Debian-based distributions in future). Within that, we have the following workspaces:
Name |
Purpose |
Owners |
Contributors |
infrastructure such as Debian archive mirroring and image building |
debusine staff |
|
|
uploads intended to enter Debian via the upload-to-* workflows |
debusine staff |
Debian developers |
Workflows
Most interaction with Debusine happens using workflows.
The developers workspace currently has the following workflow templates available:
Name |
Purpose |
Task data reference |
Create a workspace for an experiment |
||
Build, test, and upload to Debian experimental |
||
Build, test, and upload to Debian unstable |
||
Build, test, and upload to Debian bookworm (via proposed-updates) |
||
Build, test, and upload to Debian bookworm-security (only release in coordination with security team!) |
||
Build, test, and upload to Debian bullseye-security (only release in coordination with LTS team!) |
About the “upload-to-*” workflows
If you are a Debian developer just discovering Debusine, the upload-to-* workflows are the most interesting workflows for you to try out. They need a source package as input, and will build binary packages for 4 architectures, perform lots of QA checks that you will be able to review through a web interface and eventually offer you to remotely sign and upload the source package to Debian (if you are happy with the results).
If your package must go through NEW, either for a new binary package, or because it's entirely NEW, the above workflows are not suitable yet because they will not upload any binary package alongside. See https://salsa.debian.org/freexian-team/debusine/-/issues/826 for a discussion of this issue.
If you have dput-ng installed, you can start those workflows straight from dput. The target distribution name will be used to figure out which workflow to start:
$ dput debusine.debian.net hello_1.0-1_source.changes
Uploading hello using debusine to debusine.debian.net (host: debusine.debian.net; directory: /)
running debusine-check-workflow: check debusine workflow for distribution
running checksum: verify checksums before uploading
running suite-mismatch: check the target distribution for common errors
running gpg: check GnuPG signatures before the upload
Not checking GPG signature due to allow_unsigned_uploads being set.
Uploading hello_1.0-1.dsc
Uploading hello_1.0.tar.xz
Uploading hello_1.0-1_source.changes
Created artifact: https://debusine.debian.net/debian/developers/artifact/ARTIFACT-ID/
running debusine-create-workflow: create a debusine workflow
Created workflow: https://debusine.debian.net/debian/developers/work-request/WORKFLOW-ID/
If you have at least dput-ng version 1.43~bpo12+1 installed, then you can also set workflow options here. For example:
$ dput -O debusine_workflow_data.enable_reverse_dependencies_autopkgtest=true debusine.debian.net hello_1.0-1_source.changes
See the task data reference for the options you can set. Remember than you can only pass options that have been left unspecified by the underlying workflow template.
Go to the URL printed after "Created workflow" (which will contain an actual workflow ID rather than the placeholder in the example above) to monitor the progress of your workflow (it doesn't auto-reload, so you have to manually reload the page from time to time).
One of the "steps" is named "Wait for signature on upload for …". When that work request is marked as "Running", then you can decide to trigger the upload to Debian. If you are happy with the results of the QA checks, and want to upload the package to Debian, click on that "Wait for signature" work request and run the debusine provide-signature ... command shown there, after which Debusine will upload the package to Debian for you.
If you are not happy with the results of the QA checks, you can cancel the upload workflow by clicking on the red "Abort work request" button on the top right, either on the workflow page or in the "Waiting for signature" work request page.
About the “create-experiment” workflow
This workflow lets you create a workspace where you have owner-level permissions. You can do so with the help of debusine create-workflow, which can be used to start a workflow from any one of a set of defined workflow templates in a workspace:
$ debusine create-workflow --workspace developers create-experiment <<EOF
experiment_name: "cjwatson_test"
EOF
The YAML data provided on stdin constitutes "task data" that is fed to the workflow. Note that task data items that are set by the workflow template are fixed and cannot be changed when starting the workflow. Other items are free for you to set if needed.
See the workflow's task data reference for the options you can set. Note that the workspace auto-expires after 60 days of inactivity (you can increase that delay by setting the appropriate parameter at creation time).
If you wonder, what you can do with that personal workspace, you can have a look at https://salsa.debian.org/stefanor/debusine-rebuilds for an example. Stefano has some scripts to perform mass rebuilds and analyze build logs. In the future, we aim to integrate such features directly in Debusine.
Frequently Asked Questions
How does the dput integration work?
Under the hood, the dput plugin imports the source package as a new artifact in the target workspace and then triggers a new workflow on it. It chooses the workflow to start based on the mapping in /etc/dput.d/profiles/debusine.debian.net.json.
Here's how you can reproduce this manually. You can upload a package to Debusine as follows:
$ debusine import-debian-artifact --workspace developers hello_1.0-1_source.changes
result: success
message: New artifact created in ...
artifact_id: ...
You can then start a workflow on that upload, replacing ARTIFACT-ID with the value on the first line beginning with artifact_id: in the output of the previous command:
$ debusine create-workflow --workspace developers upload-to-unstable <<EOF
source_artifact: ARTIFACT-ID
enable_reverse_dependencies_autopkgtest: true
EOF
Find your new workflow on https://debusine.debian.net/debian/developers/workflow/ and watch its progress there, which in this case will include automatically running autopkgtests of all the package's reverse dependencies in unstable.
How can I make sure that debusine provide-signature is really signing the correct .changes file?
We are indeed considering to add some extra client-level checks so that you can ensure that the file submitted for signature by Debusine is really the .changes file that you are expecting. See https://salsa.debian.org/freexian-team/debusine/-/issues/816
That said Debusine is free software, you can inspect its source code to understand what it does. And debusine.debian.net is managed exclusively by Debian developers. It doesn't mean that it's free of bugs or vulnerabilities, but since we aim for Debian to adopt it, we are doing our best to build a secure, reliable and trustworthy infrastructure.
Where to get help?
#debusine: Join our IRC channel and ask right away
salsa issues: Tell us what you need
