The Debian Octave Group (DOG) is a collaborative effort for maintaining the Octave-related Debian packages, in particular those released by the Octave-Forge project.

Anyone is invited to participate. There is no need to be a Debian Developer. If you are interested, send an email to the development list (see below).

Maintained packages

Mailing list

Development is coordinated through the debian-octave list on Debian list server. Subscription and posting are open to anyone.

Git repositories

Development is coordinated through Git repositories, grouped under the Debian Octave Group homepage at Salsa.

Our git workflow is the following:

.gitignore file

In the past, we used to have a top-dir .gitignore file in our Git repositories. This was useful for ignoring the files left over by the package building process. This technique has some drawback, though, since this may interfere with the eventual .gitignore file shipped by the upstream authors and the setting merge-mode = merge in gbp.conf is needed. We then decided to have .gitignore files only in the 'debian/ directories. This means that, after the package is built, some Git commands (e.g. git status and git diff`) non-Debian-related changes in the repository will be indicated. It is then recommended running the following commands:

./debian/rules clean
quilt pop -af
rm -rf .pc

If there are any files left in the top-dir after running the commands above, then their names should be included in the debian/clean file. This would probably be an issue with the upstream package and should be reported to the upstream authors.

URL aliases

You may want to create an alias for the URL of our Salsa homepage, as follows:

git config --global url."".insteadOf pkg-octave-team:

(this assumes that you are accessing Salsa with SSH; replace the corresponding URL if you use another mean)

Then you can clone repositories as follows:

gbp clone --git-pristine-tar pkg-octave-team:$pkg

(replace $pkg by package name, e.g. octave)

Pristine-tar default option

If you’re tired of always giving the --git-pristine-tar option to gbp (or if you fear forgetting it), you can set the following in ~/.gbp.conf:

pristine-tar = True

Note that all packages of the DOG have now the following file debian/gbp.conf, so that the pristine-tar is always True :

debian-branch = debian/latest
upstream-branch = upstream/latest
pristine-tar = True

Subscribing to git commit notifications

Git commit notifications are delivered through

You can individually subscribe to commit notifications:

( echo "subscribe $pkg"; echo "keyword $pkg + vcs" ) | mail

It is also possible to subscribe to all git commit notifications by subscribing to the Debian Octave Group at (making sure you have enabled the vcs keyword).

Check list for the Octave-Forge packages

  1. Bump the Standards-Version to the latest release.
  2. Set the Uploaders field as described below.
  3. The recommended debhelper compat level is 11.
  4. We use a machine-readable debian/copyright with the 1.0 specification. Generating this file can be simplified by the following command:

    licensecheck -r --copyright -c  '\.m|\.cc|\.hh|\.c|\.h|\.f' . | /usr/lib/cdbs/licensecheck2dep5

    Note that you will have to update the Format line using the finalized URL for version 1.0. If you are using CDBS version 0.4.103 or later, the URL will be that for version 1.0.

    You can also automatically fix some errors in your file using the following command (from package libconfig-model-perl):

    cme fix dpkg
  5. Use the SourceForge redirector in the debian/watch file (bump format version to 4 if needed):


Octave Forge packages not in Debian

Candidates for packaging

The following packages are listed as maintained by the upstream authors and are not yet in Debian:

Packages that should not enter Debian

Packages that have been in Debian at some point but were removed

Uploaders Field

The Uploaders field should normally list the team member(s) that are personally interested in the package and take the primary responsibility for maintaining it. Maintaining this field up-to-date gives a better overview of responsibilities within the team (in particular, it will make individual QA pages more relevant). Also note that team members not in the Uploaders field of a given package can still do Team Uploads, for example for fixing RC bugs or handling transitions.

There are however some packages that nobody is personally interested in for the time being, but which are nevertheless maintained by the team in the interest of our users. The Uploaders field of those packages should list all the team members willing to do this collective maintenance work, who are:

The packages in this situation are:

Work in progress

ToDo Items

The following list contains things that should be done at some point in the future.

Obsolete material