This tutorial is generated courtesy of Karl Kornel from Stanford Research Computing. The ascii art is amazing, if you don’t care to build Singularity on Debian please scroll down to appreciate it in it’s entirety. Thank you Karl!
NOTE: that an official debian initiative is underway, and this tutorial is for those interested in digging into the build.
For the purposes of this tutorial, we will assume that the name of your remote is “stanford” and your username is “vsoch.”
{% include toc.html %}
This is for people who know what’s going on, and just want help remembering the command sequence.
git init .
git remote add lbl git@github.com:singularityware/singularity.git
git remote add stanford git@github.com:vsoch/singularity.git
git fetch lbl
for i in master 1.x 2.x gh-pages; do
git checkout lbl/$i
git checkout -b $i
git branch -u stanford/$i
done
git push --all stanford
git push --tags stanfordReleasing an upstream version, with the change in source format, and adding the appropriate backport suffix to the version number.
git clone https://github.com/vsoch/singularity.git
git checkout 2.1.2
git checkout -b stanford-2.1.2
# Change debian/source/format to 3.0 (git)
# Add git debian/control's Build-Depends list
git commit -m 'Changing to git source format' debian/control debian/source/format
dch -D xenial-backports -v 2.1.2-1~sbp16.04.1+1 'Releasing for Xenial'
git commit -m 'Update changelog for release' debian/changelog
git tag -s stanford/2.1.2-1_sbp16.04.1+1
git push
git push --tagsTo set up and build on a single system (same release only):
aptitude install -y build-essential debhelper dh-autoreconf git
dpkg-buildpackage -us -ucTo set up and build on the build server:
ssh $USER@$BUILDSERVER
cd $SCRATCH/$USER
test -d build-area || mkdir build-area
git clone https://github.com/vsoch/singularity.git
cd singularity
git checkout stanford-2.1.2
ls -d /var/cache/pbuilder/base*.cow
pdebuild --pbuilder cowbuilder --buildresult ../build-area -- \
--basepath /var/cache/pbuilder/base-xenial.cow
rm ../singularity_*.dsc ../singularity_*.git \
../singularity_*.changes ../singularity_*.build
cd ../build-areaSingularity is unusual from a Debian perspective, in that the Debian packaging data are part of the upstream repository.
Normally, at least with Git repositories, the flow looks like this:
==================
|| Upstream ||
|| Repo ||
|| ||
|| /--------\ ||
|| | master | ||
|| | branch | ||
|| \----v---/ ||
=========v========
I
=========v===============================
|| /----v-----\ /--------------\ ||
|| | upstream | | pristine-tar | ||
|| | branch +---->| branch | ||
|| \----v-----/ \-v------------/ ||
|| I I ||
|| I /--------\ I ||
|| I | debian | I ||
|| I | dir. | I ||
|| I \-v------/ I ||
|| I I I ||
|| /----v---v-\ I ||
|| | master | I Debian ||
|| | branch | I Maintainer's ||
|| \----v-----/ I Repo ||
=========I=============I=================
I I
/-v-------------v--\
| Debian package |
\------------------/The Debian maintainer is responsible for pulling in code from upstream, adding the debian directory (which includes both metadata, build instructions, and patch files to change code), testing, and building the resulting Debian package(s).
With Singularity, there is no “Debian Maintainer’s Repo”, because the debian directory is in the upstream repository. On the one hand, this is nice because we only have to deal with a single repository! However, there are two challenges that are introduced by this:
To deal with point 1, we do two things: We make a new branch, and we add a commit on that branch which updates the changelog (the release name and version number come from the changelog).
To deal with point 2, we change how Debian deals with the source code: Instead of expecting a source tarball (with the 3.0 (orig) or 3.0 (quilt) source formats), we use an experimental format (3.0 (git)) which simply bundles up the entire Git repo as the source!
With the two changes we will make, the actual flow will look like this:
=================================
|| Upstream ||
|| Repo ||
|| ||
|| /---------\ /----------\ ||
|| | release | | various | ||
|| | tags | | branches | ||
|| \----v----/ \----v-----/ ||
=========v============v==========
I I
=========v============v====================
|| /----v----\ /----v-----\ Our ||
|| | release | | various | Repo ||
|| | tags | | branches | ||
|| \----v----/ \----------/ ||
|| I ||
|| I /-------------\ ||
|| I | debian dir. | ||
|| I | changes | ||
|| I \--v----------/ ||
|| I I ||
|| /----v-------v-\ /--------------\ ||
|| | stanford-XXX | | stanford/XXX | ||
|| | branches +---> tags | ||
|| \--------------/ \-------v------/ ||
|| I ||
===============v===============v===========
I I
I /---------v--------\
\-----> Debian package |
\------------------/The overall process goes like this:
master, 1.x, and 2.x).2.1.2) and branch it (making the stanford-2.1.2 branch)..tar file.The following sections describe each of those four overall steps.
Singularity has their repository in GitHub, so cloning the repository is just a matter of forking it. However, if you want your repository to live somewhere other than GitHub, you can do this process:
First, create a blank repository, add the upstream GitHub as a source, and fetch:
git init .
git remote add lbl git@github.com:singularityware/singularity.git
git fetch lblNext, add a new remote representing your upstream repository:
git remote add stanford git@github.com:vsoch/singularity.gitCheck out the branches you care about, and link them to your upstream:
for i in master 1.x 2.x gh-pages; do
git checkout lbl/$i
git checkout -b $i
git branch -u stanford/$i
doneFinally, push everything to your new upstream:
git push --all stanford
git push --tags stanfordFrom time to time, you should pull in upstream changes, so that your repository is in sync. Here’s how to do that.
First, create a blank repository, and add both your remote and the upstream remote. Then, fetch from both:
git init .
git remote add lbl git@github.com:singularityware/singularity.git
git remote add stanford git@github.com:vsoch/singularity.git
git fetch --allNext, synchronize all changes from the branches we know about:
for i in master 1.x 2.x gh-pages; do
git checkout stanford/$i
git checkout -b $i
git branch -u stanford/$i
git merge lbl/$i
doneThen, run git branch -r and look to see if upstream has any new branches. If they do, then create matching branches on your end:
for i in new1 new2; do
git checkout lbl/$i
git checkout -b $i
git branch -u stanford/$i
doneFinally, push everything up to your copy:
git push --all stanford
git push --tags stanfordIf you are leaving upstream’s branches untouched, then all of the merges should be fast-forward merges. If, however, you are making changes in upstream branches (like master, or 2.x), you should expect either a non-fast-forward merge or a conflict. It’s up to you to deal with them.
When upstream makes a release, we should do the same. Even if we aren’t going to package it, making the release now means that packaging will go faster later!
First, if you don’t have the Git repository checked out, get it now:
git clone https://github.com/vsoch/singularity.gitNext, either switch to the branch you want to build, or check out the tag for the release you want. In this case, we are getting 2.1.2 (which is a tag).
git checkout 2.1.2Then, create a new branch for that specific version, to which we’ll add our changes:
git checkout -b stanford-2.1.2Now that we have our branch, there are two things we have to check:
Once those changes are made, commit them.
git commit -m 'Changing to git source format' debian/control debian/source/formatIf you are working from your own Git repository, then you should also change the “Vcs-Git” and “Vcs-Browser” fields in debian/control. You should also add yourself to the “Uploaders” field. Then, once again, commit.
Next, you need to update the changelog. This is what sets the release, and also the version number!
dch -D xenial-backports -v 2.1.2-1~sbp16.04.1+1 'Releasing for Xenial'
git commit -m 'Update changelog for release' debian/changelog(See the “Version Numbering” section for help on deciding what version number to use.)
Finally, make a new tag representing your version.
git tag -s stanford/2.1.2-1_sbp16.04.1+1(We changed the ~ in the version number to an _ because Git doesn’t allow the tilde character in tag names.)
When making the tag, an editor will launch, giving you a space to enter a tag description. Simply re-use the entry you made into debian/changelog (just copy-paste the entire changelog entry, including the header and the date line).
If you don’t have a PGP key, then change -s to -a.
Finally, push everything, and you are ready to build!
git push
git push --tagsAt this point, you can either go on to build the package, or you can stop, and the release will remain ready for when you do want to build.
Version numbering is interesting in Debian, because you need to keep track of at least two things:
But, you may also have to add other things:
When constructing the package version number, there are two rules, and one very important exception to remember:
2.1.2-1, the parts are 2, .1, .2, and -1.~) sorts before everything else, including the empty string.Because of that exception, if you have a test build (like 2.1.2-1~testFoo+1) or a backport (2.1.2-1~bpo8+1), Debian will treat those versions as being older than a released version (like 2.1.2-1 or 2.1.2-1ubuntu1).
More information is available in the Debian Policy Manual, sections 3.2 and 5.6.12.
Given all of the above, here are recommended version numbers to use:
VERSION-1~sbp8+1, where the 8 is the version number of the Debian release (Debian jessie is version 8).VERSION-1~sbp16.04+1. Similarly, 16.04 is the Ubuntu version.VERSION-1stanford1. We should then try to get those code changes applied upstream.We use a different form for code changes because we want that to remain newer than anything that comes in through Debian/Ubuntu upstream (lest we lose our changes in an upgrade). Since backports don’t have code changes, they are lower-priority.
Once you have a release tagged and pushed, it is time to build the package. Before you start, you have to make a choice: You can either build the package on your own system, or you can use the Debian build service. Either way, the build products are the same.
The easiest way to build Singularity packages is on a system that you’ve already got. On the one hand, you don’t have to maintain a separate infrastructure! However, you will only build for the release that you are running on that system. So, if you’re running Debian wheezy, you’ll only be able to build packages for Debian wheezy.
The other downside is that you’ll have to install all of the build dependencies system-wide. However, that’s not a big problem here, because Singularity’s needs are very simple. There are four packages (plus all of their dependencies) that need to be installed:
build-essential is a single package that installs (via dependencies) all of essential things that are required for building Debian packages.debhelper is a suite of scripts that help to automate the Debian package-building process. Almost all of the steps in making a package, such as generating the list of changes, are orchestrated by debhelper. (Singularity uses debhelper, which is why this is required.)dh-autoreconf is an optional debhelper component that ensures autoreconf is run before the software’s configure script. This package also has the various autotools (autoconf, automake, etc.) as dependencies, so we can be sure they are also installed. (Singularity uses dh-autoreconf, which is why this is required.)You only have to do this the first time you build on this system.
aptitude install -y build-essential debhelper dh-autoreconf gitNow it’s time to build the package! Here’s the command to use:
dpkg-buildpackage -us -ucThat’s it! That one command triggers an entire sequence of commands that will archive the source, build it, package the output, and create ancillary files. The command output is relatively good at explaining what’s going on, so I won’t reproduce or expand on that here.
If you plan on building for a release that is not your own, or you are unable to install all of the build dependencies, then you should use the Debian build server!
First, log in to the build server, and go to your scratch directory. Make a build-area directory, if you don’t have one already:
ssh $USER@buildserver
cd $SCRATCH/$USER
test -d build-area || mkdir build-areaCheck out the repository, go into it, and then check out the branch or tag that you want to package:
git clone https://github.com/vsoch/singularity.git
cd singularity
git checkout stanford-2.1.2Look at the list of available releases to build against, and then pick one:
ls -d /var/cache/pbuilder/base*.cowOnce the release you want is available, build your package!
pdebuild --pbuilder cowbuilder --buildresult ../build-area -- \
--basepath /var/cache/pbuilder/base-xenial.cowThe pdebuild process takes care of several different things:
cowbuilder to spawn a new COW (copy-on-write) environment, based on the release you specify, and start a root session within the environment.root).Once the build process is complete, the final products are placed into the build-area directory you created, but some intermediate products are left in the parent directory, which you should delete:
rm ../singularity_*.dsc ../singularity_*.git \
../singularity_*.changes ../singularity_*.buildThat’s it! You now have stuff that you can install or upload.
Once package-building is complete, you should have three or four build products:
.deb file is your package! You can install this directly with dpkg -i DEB_FILE_PATH..build is a complete log of the steps taken to build your package, as well as the output (standard out and standard error) from those steps. If you are building locally, then this file might only be created if there was a problem. If you are using the build server, this file is always created..git file is your entire Git repository, packed up in a single file. This is known as a Git Bundle..dsc file is similar to your .changes file, except this file only contains information on the source. This file contains the information that someone else would need to get the source code you used, install the build dependencies, and then build the binary package themselves..dsc and .changes files are normally signed during the package-build process; this gets skipped normally by pdebuild, and gets disabled on dpkg-buildpackage by the -us -uc options. If you plan on uploading these files to a Debian repository, then you should sign them, either manually or using the debsign command.
debsign singularity_*.changes
You’ll be prompted twice, once to sign the .dsc file, then again to sign the .changes file.
Once signed, you can upload using dput:
dput stanford singularity_*.changesccThat’s it! Once your servers upgrade, they should see the newer package version as an option.
Ensuring Long-term Trust and Reliability of SIF Images: What You Need to Know As container runtimes technologies become more prevalent, it presents a dilemma for government, public, and private sector organizations. They must consider the long-term implications of...
The Apptainer project has recently published CVE-2023-30549. The associated
Enabling Portable and Secure Computing Environments for High-Performance Workloads.As part of their ongoing efforts to streamline workflows, enhance productivity, and save time, engineers, and developers in enterprises and high performance computing (HPC) focused...