| CARVIEW |
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 and Debian maintainers 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 on debusine.debian.net.
Contents
Authenticating to debusine.debian.net
Install the debusine-client package, which is in trixie-backports and forky (and newer). Older versions are in bookworm-backports and trixie but we recommend using the latest version. 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 |
||
Create a workspace for a repository |
||
Build, test, and upload to Debian experimental |
||
Build, test, and upload to Debian unstable |
||
Build, test, and upload to Debian trixie (via proposed-updates) |
||
Build, test, and upload to Debian trixie-security (only release in coordination with security team!) |
||
Build, test, and upload to Debian trixie-backports |
||
Build, test, and upload to Debian trixie-backports-sloppy |
||
Build, test, and upload to Debian bookworm (via bookworm-proposed-updates) |
||
Build, test, and upload to Debian bookworm-security (only release in coordination with security team!) |
||
Build, test, and upload to Debian bookworm-backports |
||
Build, test, and upload to Debian bookworm-backports-sloppy |
||
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 5 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).
There is no need to sign the input source package, you will be offered to sign it at the end of the workflow.
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 (Debian Trixie has the version 1.43), then you can also set workflow options here. For example:
$ dput -O debusine_workflow_data.enable_reverse_dependencies_autopkgtest=false debusine.debian.net hello_1.0-1_source.changes
(This disables the autopkgtest jobs on reverse dependencies of your package)
See the task data reference for the options that exist. Remember than you can only pass options that have been been whitelisted as "Runtime parameters" in the workflow template definition (see links in the table above).
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.
Using the “upload-to-*” workflows without triggering an upload
In addition to being a pipeline to the Debian archive, the upload-to-* workflows can be used as a test bed on several architectures for your packages without actually uploading anything at the end. Use the -O debusine_workflow_data.enable_upload=false option to dput.
If your current entry in debian/changelog has a special value like "UNRELEASED", or when the target release is not mapped in /etc/dput.d/profiles/debusine.debian.net.json, you can call dput with -O debusine_workflow=WORKFLOW-NAME to select the appropriate workflow to start. For example, if you want to test your UNRELEASED upload against unstable:
$ dput -O debusine_workflow=upload-to-unstable -O debusine_workflow_data.enable_upload=false debusine.debian.net hello_1.0-1_source.changes
Using the “upload-to-*” workflows for uploads to NEW
If you know that the upload will hit the NEW queue for review by the ftpmasters, then the upload needs to include binary packages too. You can perform this by using the following dput options:
$ dput -O debusine_workflow_data.upload_merge_uploads=true -O debusine_workflow_data.upload_include_binaries=true debusine.debian.net hello_1.0-1_source.changes
See https://salsa.debian.org/freexian-team/debusine/-/issues/826 for a discussion about this issue.
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
suffix: "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.
Repositories
Debusine can host your package repositories. As shown by the "PPA" system in Ubuntu, there are various uses for this sort of thing, such as:
- short-lived experiments, for things like transitions that you intend to land in Debian soon and just need to finish integrating and testing first
- projects that aren't yet packaged in a way that meets Debian policy, but where it's useful to distribute them in a packaged form anyway
- automatic daily builds of packages for upstream projects
This is how you would set up a package repository, assuming that you have at least debusine-client 0.14.1 installed.
Let's say that you want to create a repository called "widgets".
If your repository is for a short-lived experiment, then you can use the create-experiment workflow, which arranges for it to expire after a period of inactivity. Otherwise, start by running the create-repository workflow:
$ debusine create-workflow --workspace developers create-repository <<EOF
suffix: "yourname-widgets"
EOF
This creates a child workspace that you own called "r-yourname-widgets". This workspace may contain multiple suites, each of which corresponds to a different base version of Debian. Let's say you intend to publish amd64 and arm64 packages for sid as well as backporting them to trixie. You would then create two suites:
$ debusine archive suite create --workspace r-yourname-widgets \
--architecture all --architecture amd64 --architecture arm64 \
--base-workflow-template upload-to-unstable \
sid-widgets
$ debusine archive suite create --workspace r-yourname-widgets \
--architecture all --architecture amd64 --architecture arm64 \
--base-workflow-template upload-to-trixie \
trixie-widgets
Notice that you need to specify a base workflow template, which should be one of the existing debian_pipeline ones; this is used to copy over defaults such as environment configuration. The suite name is up to you, but for now we recommend that you include the base Debian suite name but add your own suffix, to avoid running into issue #495. If you need to, you can edit the resulting configuration later using debusine collection manage and debusine workflow-template edit.
To upload to your new suites, you can use options to dput (or create your own profiles in ~/.dput.d/profiles/ if you prefer):
$ dput -O debusine_workspace=r-yourname-widgets -O debusine_workflow=publish-to-sid-widgets debusine.debian.net widgets_1.0-1_source.changes
$ dput -O debusine_workspace=r-yourname-widgets -O debusine_workflow=publish-to-trixie-widgets debusine.debian.net widgets_1.0-1~bpo13+1_source.changes
You can find APT configuration for each suite by going to https://deb.debusine.debian.net/debian/r-yourname-widgets/. Signing keys will only be generated once something has been published to the repository.
Terms of service
Detailed terms of service are coming soon, but briefly, packages must be under licences that allow distribution by Debian, and debusine.debian.net is intended primarily for work that could reasonably end up in Debian. As the service operator, Freexian reserves the right to remove repositories for any reason, and is likely to do so in cases of violated licence conditions or packages that Debian has chosen to not accept. If you need to host packages that are not suitable for debusine.debian.net, you can contact Freexian to discuss commercial arrangements, or set up your own Debusine instance.
Limitations
Repository hosting is a new service, announced in December 2025, and we are actively working on improving it. At the moment, you may notice some of these problems:
There is no garbage-collection of superseded package versions: https://salsa.debian.org/freexian-team/debusine/-/issues/1073
We do not have a tool for copying packages between suites, which would be useful for things like staging areas: https://salsa.debian.org/freexian-team/debusine/-/issues/1113
- We do not have tools for changing overrides or removing packages
See also our list of repository issues.
About user management and permissions
When you login on debusine.debian.net with Salsa for the first time, if you are a Debian developer or a Debian maintainer, then a Debusine account is automatically created. The username of that account is your primary email on salsa.debian.org.
To verify if you are a Debian developer, it relies on the group membership exported by Salsa: if you are part of the [debian group]debian group on salsa, then the account is created and it is added to the Debian group on debusine.debian.net.
To verify if you are a Debian maintainer, it will query nm.debian.org to know if that salsa identity is known to be a Debian Maintainer. If yes, then the account is created and it is added to the Maintainers group.
Being member of one of those two groups grants you contributor-level permission on the debian/developers workspace (which basically lets you upload artifacts and start workflows and that's all).
After the initial account creation, no further synchronization will happen. We plan to setup some automatic mechanism to disable accounts when the person has lost their developer/maintainer status (see https://salsa.debian.org/freexian-team/debusine/-/issues/976).
At this point, Debusine also doesn't have any feature to lets you change your account in any way (no change of email, no change of username, no change of the profile name, no ability to remove yourself from a group, etc.)
So in the mean time, if you need to change something on your account, if you want to revoke some permissions that you have been granted, if you resign from Debian, please open a support issue here: https://salsa.debian.org/freexian-team/debusine.debian.net/support
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.
And that mapping is provided by the package debusine-client
Install debusine-client and dput debusine.debian.net hello_1.0-1_source.changes will start to work after #Authenticating to debusine.debian.net is done.
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_upload: false
EOF
Find your new workflow on https://debusine.debian.net/debian/developers/workflow/ and watch its progress there, which in this case will not trigger any upload to the Debian archive.
How can I make sure that debusine provide-signature is really signing the correct .changes file?
You can use the --local-file option with debusine provide-signature command to use local files instead of the one downloaded from Debusine server. It will sign the provided file and send it.
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.
Can I prepare an NMU and upload it to the delayed queue with Debusine?
Yes, use dput -O debusine_workflow_data.upload_delayed_days=5 debusine.debian.net foo_source.changes to perform the upload.
Where to get help?
#debusine: Join our IRC channel and ask right away
salsa issues: File an issue in the Debusine project if you have found a bug or have an idea of improvement for the software
support issues: File an issue in the support project if you need help from administrators to fix something on the debusine.debian.net instance (removal of account, drop permissions, change of email, etc.)
DebusineDebianNet (last modified 2025-12-23 22:27:33)
- Changes made after 24 July 2025 00:00 UTC are available under Creative Commons Attribution-ShareAlike 4.0 International unless otherwise noted.
- Debian privacy policy, Wiki team, bugs and config.
- Powered by MoinMoin and Python, with hosting provided by Metropolitan Area Network Darmstadt.
