UP | HOME

The Northwestern MS Robotics Personal Package Archive

MSR PPA

A personal package archive (PPA) is a way for users of Ubuntu to distribute personal packages. Northwestern MS in Robotics has a PPA at https://launchpad.net/~numsr/+archive/ubuntu/robotics.

This document describes how to make a PPA and provides details about the NU MSR PPA.

The following steps should be done from Ubuntu LTS

How To Make A PPA

  1. Sign up for a launchpad.net account
  2. Create an OpenPGP key: gpg --full-gen-key
  3. See the keys with gpg --list-keys
  4. Send your key to the Ubuntu keyserver: gpg --send-keys --keyserver keyserver.ubuntu.com <keyid>
  5. Wait 10 minutes for the server to update
  6. In your launchpad profile, add the pgp key (use gpg --fingerprint to get the fingerprint you needed)
  7. Assuming your email is not setup with gpg, copy the encrypted message to a file and decrypt with gpg -d, then follow the instructions.
  8. While logged into launchpad, assign (or affirm) the Code of Conduct

How To Rebuild a Debian Package

From a Source Debian

  1. Make sure the pgp keys are setup on the system you are building the package on.
  2. Install the devscripts package
  3. Add deb-src to the Types: stanza in /etc/apt/sources.list.d/ubuntu It should look like Types: deb deb-src
  4. sudo apt update
  5. apt build-dep <packagename> installs the build dependencies
  6. Create a working directory <workdir> and cd <workdir>.
  7. apt source <packagename> downloads the source package to <workdir>.
  8. The debian build process likes to spew and refer to files in the parent directory.
    • To help with this it makes sense to copy the workdir when issuing a new debuild command.
  9. The package download should have created a directory with the upstream package name and version <package>. Enter this directory
  10. Most debian packages use the Quilt patch management system to manage patches
    • Use quilt push -a to make sure the package is up-to-date
    • You can also track things as patches using quilt if you would like:
      • quilt new patchname.patch creates a new patch
      • quilt add filename adds a file to the patchset. This must be done prior to editing the file
      • When done editing use quilt refresh to apply the patch.
  11. Use dch to edit debian/changelog, adding a new entry for yourself outlining the changes you made
    • Be sure to boost the version number in the changelog.
    • If you have just made changing to the packaging, change the debian version (the part after the -)
    • Appending a ~<N> makes the package be considered less new than the version without the ~<N> appended.
    • Name and email address should likely be consistent with the pgp key you use to sign the ppa.
    • These packages are very finicky about the version naming scheme, and various items have different semantic meanings. For my purpose, incrementing the revision number seems to work best.
  12. The debian/control has information about package dependencies
  13. When ready to build run debuild -k<your-pgp-key-id> -b (from a new <workspace> directory)
    • You may wish to install and test the package.
    • The key id is listed on the ppa homepage (e.g., https://launchpad.net/~numsr for NU MSR's ppa) under OpenPGP keys
  14. When ready to upload to the ppa run: debuild -k<your-pgp-key-id> -S -sa
  15. If the source built successfully upload the packages using dput ppa:<username>/<ppaname> <package_name>.changes (according to the instructions on the ppa page).
  16. Refresh your ppa homepage. It may take a little while. If the build failed, you will get an email with some diagnostic information.
  17. There is no need to keep track of your changes in git: once uploaded to launchpad you can see the source and your changes to it by downloading the source package.
    • Essentially, your changes are being tracked in launchpad. This is fine for changes to the packaging itself, but if you are changing source code you likely want to make the changes in a fork or even submit them to the upstream project.

Package Format

There are two package formats, as specified in debian/source/format

  1. 3.0 (quilt) this uses the quilt patch system and assumes source code is provided as a separate tarball from the debian/ folder
  2. 3.0 (native) this mode allows the debian/ folder to be directly in the repository
    • The downside of native is that the full source code becomes part of the debian source package, making it harder to track what Ubuntu-specific changes were made
    • There is worse Launchpad performance since the full code must be uploaded even if only the debian/ directory changes.

Quilt Packages

  1. Fork the package to package.
  2. Make the original tarball:
    • tar --exclude=.git --exclude=debian/ -czf package_name_version.orig.tar.gz git_folder_name/ .
  3. Commit to your modification branch
  4. Use git format-patch commit to create a patch set and save it somewhere
  5. On the original (non-fork) branch create the debian/ directory and required files

4.. export QUILT_PATCHES=debian/patches

  1. Use quilt import on each patch to apply the patches

RT Kernel

  1. Get RT Kernel sources (must get via git to make the debian source package) git clone https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/ Checkout the latest rt branch
  2. Make menu config and setup the kernel.
    • I made a custom version based on the config available in /boot/config
    • The kernel is designed for x86 systems and removes support for a lot of legacy hardwaree tc
    • It's nto fully minimal as it tries to stay close to ubuntu defaults
  3. In kernel source tree: make menuconfig
  1. To build a debian package: make deb-pkg
    • Test this by installing it
  2. To prepare for the ppa
  3. Use make srcdeb-pkg to make the source package
    • This creates a gzip of the package directory.
    • The original source is the orig.tar.gz file
  4. What we need to do is
    1. Extract the orig.tar.gz file to a file that matches the name of what you actually want to call the package
  5. Unpack the source package to a new directory
  6. tar czvf name_of_package.orig.tar.gz source_dir
    • This creates the original tarball
  7. Extract the source tarball into the extracted source directory
  8. Edit control and changelog to set the version and the package name that you want
  9. debuild -k<KEYID> -S -sa to build the source package that can be uploaded to the ppa

Realsense

There are two Realsense packages in the PPA

realsense-dkms

  1. The realsense has some slightly modified kernel drivers to help it report timing information better.
    • The realsense will work without this package, but it timestamp information is more reliable if you use it.
  2. The process by which Intel releases it's kernel patches is not entirely clear, but the build process involves scripts and patches under the librealsense2/scripts directory
  3. Intel has it's own apt repository that contains binary packages for the dkms driver
    • Each of these packages belongs to a specific kernel
  4. The version I provide on the PPA is for the 6.8.0 kernel. It was created by
    1. Downloading and extracting the files from the binary librealsense2-dkms package
    2. Recreating the source package from scratch from the binary package

librealsense2

  1. This version now matches the upstream version, and differs only from the ros-<version>-librealsense2 package based on it's compilation options
    • CUDA is enabled (in tests of e.g., aligning frames, this results in a 10x speedup)
    • Python bindings are provided
    • The intel realsense utilities are provided
    • The udev rules are installed

Uncloud-init

  • A replacement for cloud-init that serves the purpose of providing the minimal cloud-init functionality needed to perform an installation of Ubuntu.
  • The README.md in the package provides the details

Network Manager

  • Removes dependencies of Network Manager on netplan.io

Author: Matthew Elwin.