Notes About Specific Packages


Location in the source tree: debathena/debathena-thirdparty

The purpose of this package is to provide "third party software". Historically, "third party software" was software installed in lockers, and not in the release. This includes commercial software like MATLAB, but also included a lot of Free Software, because back in the day, the base system didn't include a lot of the packages that are commonplace in Linux distributions. So the name is now a historical accident, but the purpose of this package is to depend on other packages in Ubuntu, to ensure they're installed on debathena-cluster machines and the dialups.

Because the list of packages changes across Ubuntu releases, it's difficult to make this a one-size-fits-all package. So it generates its list of dependencies at build time. We specify what packages we want, and we have per-distribution override lists. Internally, it uses the chdist program to determine what packages are available for what distributions. If we depend on a package, and that package is not available, the build will fail.

See BUILDING in the package's directory in the source tree for a detailed explanation of the syntax of the lists files. But basically, updating this package consists of making a change either to lists/common (to pull something in on all distros) or lists/distro-codename-goes-here to pull something in on specific distros.

OpenFoam and the APT repo

precise and trusty add additional packages to the APT repo. The OpenFoam? package provides .deb files. We do not add PPAs on the fly to cluster machines, because sometimes bad things happen, and a repo being down will cause the auto-updater to break. So we download the .deb packages for OpenFoam?, and add them to our repositories for precise and trusty with dareprepro includedeb <codename> <deb-file>. We then list those packages in the distro-specific lists above, with a +, to indicate that the package should not attempt to verify their existence at build time.

This is a hack and we should probably not do this again.


Based on the BUILDING.debathena document by jdreed, that used to be in the root level of the moira submodule.

The primary goal of the instructions there is to get a snapshot of the moira repo into our repo. There may be other effective ways to do this.

This is a non-native package, so as with any non-native package, ensure you commit changes to master and tag the release with the upstream version number. (Noting that you will have to delete the tag imported from the ops moira repo, since it will have the same name).

Note that upstream moira repo commits do not necessarily conform to our commit message standards, and it may be necessary to disable the 'update' hook on when pushing them.

  • Ensure your local copy of the debathena repo is up to date and you're on the master branch.
  • Add the Moira repo as a remote (if it's not already):
    • git remote add upstream
  • Clobber the push URL to avoid doing something dumb:
    • git remote set-url --push upstream file:///dev/null
  • Fetch master and the tags from upstream:
    • git fetch upstream master
    • git fetch upstream <upstream_tag_name_here>
  • Get the new changes:
    • cd <root_level_of_moira_submodule>
    • git checkout <upstream_tag_name_here> -- .
  • Make sure they look sane and check them in.
  • Delete the upstream tag. This step is only necessary because upstream is using the same tag names we are.
    • git tag -d <upstream_tag_name_here>
  • Tag as you would any non-native package. (or just jump to the instructions here)
  • Checkout debian and merge master into it, ensuring you pass --no-ff to force a merge commit.
  • Make any packaging changes necessary, and update the changelog.
  • Build as you would any non-native package.