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/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. Create /etc/apt/sources.list.d/ubuntu-src.sources to let =apt know where to get source packages from.

    Types: deb-src
    URIs: http://archive.ubuntu.com/ubuntu/
    Suites: noble noble-updates noble-backports
    Components: main universe restricted multiverse
    Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
    
  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. 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
  3. For packages that I make for the PPA going forward, I find it easiest to use the native format. The process goes like
    • Fork the repository in git, make whatever changes
    • Add the debian directory, in native format
    • Build the package and upload to the ppa
    • Optionally, the debian/ directory can be added to the repository, but also it is obtainable from the debian source package. It can make maintaining the fork easier to not have the debian/ directory

Git and Quilt

Quilt is used in debian packages to keep track of "upstream debian changes" and the source code version. Here is how to use git to manage the changes and turn those changes into quilt-compatible patches

I like to fork a package and make changes in the fork. I then use "git format-patch <commit>" to turn the commits to HEAD from <commit> into a patchset In the original debain package (say it's version 2.44), I then use "quilt import" on each patch created by git format-patch. Now the debian source package contains the patches made against the upstream version to debianize it, but meanwhile all my code is in git Quilt environment variable QUILT_PATCHES=debian/patches should be set

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. My version package has the python bindings compiled in, and installed
  2. It also provides ros-jazzy-librealsense2 and ros-kilted-librealsense2 so that ROS packages that depend on the realsense can be installed
    • The versions provided by ROS don't have the utilities or the python bindings.
    • This version also installs the udev rules
  3. I do not provide a cuda-version package, but you can create a cuda version by modifying debian/rules and setting BUILD_WITH_CUDA to ON under the override_dh_auto_configure
    • Including CUDA necessitates the user having CUDA installed: this is why all official binaries do not have CUDA support by default.
  4. This version of the package is based off the m-elwin/librealsense2 fork (kilted branch).
    • The debian files are not in git, they are stored in the source package.
ros-jazzy-librealsense2

This package used to be used to override the version that shipped with ROS. It required extra patches to install python bindings under the proper ROS /opt/ros directory. Instead, librealsense2 installs everything in a standard location (so it is decoupled from ROS) but it provides this package so that the dependency can be satisfied.

Author: Matthew Elwin.