Some people within DebianScience have again packaged Sage for Debian. This is one of the most complex packages in Debian and will need continual maintenance - we are always looking for new contributors! If you want to help out, read below to learn how to build the package from source, then pick one of the open tasks and get going. You can contact us via the mailing list or in #debian-science on irc.oftc.net.

Build from source

Our packages in the Debian official archives should be buildable using the normal Debian build processes. This is for users that wish to build from source, as well as build bots.

For maintainers, our development workflow is to build from our git repository. Important elements are the build dependencies of Sage, patches for Sage and a script called "pruner" that uses autoconf to determine if the necessary packages are installed.

git clone --recursive https://salsa.debian.org/science-team/sagemath.git && cd sagemath

Recursive git clone to also get sage which is included as a git submodule.

To work with this repository, you must start with Debian unstable (sid) with experimental sources enabled. It is nice - optional, but highly recommended - to do this in an schroot, which you can set up using the instructions in sbuild, after which you'll probably need to apply the following workarounds: 1. 2. Next, see debian/README.source section "Local system patches", for any workarounds you might have to apply. Then:

debian/rules build-dep-maint

Install packages that are required before installing the build dependencies.

To build the package, run:

debian/rules build-dep

Install build dependencies; you may need to run apt-get -f install afterwards. If this fails, install aptitude then try it again.

debian/rules reset

Apply patches and force-reset the upstream sage submodule.

debian/rules prune

Run the pruner script. Check that the output matches the one below.

debian/rules build

Build sage and run the test suite.

fakeroot debian/rules binary

Build the Debian packages.

The output of the pruner tells you in the end which dependencies were not found on the machine ("XXX will not come from Debian"). Since all dependencies should come from Debian, such a line normally indicates that something went wrong. The pruner should only output XXX system packages will be used. Otherwise, if you are sure that you want to try this, you could go on nevertheless. Sage will then try to download and build the missing dependencies in the build step, before Sage itself is built.

See debian/README.source for further details, such as how to debug the failing doctests. We allow a cetain number of tests to fail, it's always good to lower the number of failing tests.3

Once you are happy with the full build process, you can try a test release build:

debian/rules release-experimental

Build using sbuild, with experimental sources enabled.

Open tasks

The status pages (master, develop) give an overview about package versions in Sage and Debian. Current high-priority tasks are:

  1. Deal with RC bugs in sagemath and its dependencies (see tracker).

  2. Get the number of failed doctests down (see unstable, experimental).

  3. Upstream patches that are suitable for upstream (see series).

  4. Package new sagemath versions and dependencies in experimental, upload everything to unstable together.

See debian/TODO for more tasks and more details.

Buster roadmap

The buster freeze is approaching. Most importantly we should upload a working sage 8.4 as soon as possible. Apart from that there are also some package updates required if we want to update to 8.5 before the freeze.

Sage 8.4

Sage 8.5

Required updates:

Nice-to-have updates:

Updating Sage in Debian

Every version of Sage is tested upstream with a specific version of each dependency (see our status pages). It is not always possible to provide the same versions of all dependencies in Debian. It is however advisable to follow the versions as closely as possible, especially for specialized math packages, which tend to have less stable interfaces than general purpose libraries.

This means that each update of the package sagemath comes together with a bunch of updates of other packages. As some of these updates could break the previous sagemath version in unstable, many of these updates should first be uploaded to Debian experimental. The new version of Sage will then be uploaded to experimental as well.

Once the new Sage version has been tested in experimental and is considered ready for unstable, the batch of package updates for this version is migrated from Debian experimental to unstable. This should be coordinated and not take too long, to avoid having a broken sagemath package in unstable for a long time.

Testing migration

In order to have a working sagemath package in Debian testing at all times, the whole batch of package updates for a new Sage version needs to migrate to testing together. To this end, the dependencies should declare

Breaks: sagemath (<< x.y~)

(where x.y is the new Sage version) for at least one binary package on which the binary package sagemath depends. An exception to this are libraries with a soname jump (if sagemath depends only on the library package). In this case, the new version of the library may migrate to testing before sagemath, because the old library package will be kept around until it is not used anymore.

Links

Sage out of Debian:

Historical information:

  1. If your build fails with "Permission denied", try adding the following line to /etc/schroot/sbuild/fstab: tmpfs  /dev/shm  tmpfs  rw,nosuid,nodev  0  0 - more details here (1)

  2. If your build fails with "out of pty devices", log into the chroot using sudo sbuild-shell source:${chroot_name} then run rm /dev/ptmx && mknod -m 666 /dev/ptmx c 5 2 - more details in 817236. (2)

  3. It's perhaps "not worth it" for us to lower it to 0, since the final 20 or so are not "hard" errors but are uninteresting differences like different but equivalent symbolic mathematical expressions or slightly different random number algorithms; these are generally caused by different versions of dependencies in Debian. "Fixing" them would simply involve patching Debian's Sage to expect different values. This is good for documentation purposes but you may also decide that your time is better spent doing other, more important, tasks. (3)