Regolith is distributed as a set of interrelated Debian packages. As of Regolith 1.4, there are packages for 3 releases of Ubuntu: bionic, eoan, and focal. This page describes how code changes can be packaged such that users will get the updated code.
Debian is the packaging format and system used by Regolith. Just like Debian, Ubuntu, and other Debian-based systems, the tools and workflow used to develop and update Regolith packages works in the same manner as those system. The general process:
- Produce some code change against an existing package. In Regolith, generally there is a repo for each package, but in some cases one repo may host several source or binary packages.
- Update the Debian metadata related to the change. This may just be a
changelogentry, or could be more complex such as a new binary package, additional runtime dependencies, or updates to the build files which generate the executable code.
- Do local testing and then push updates to GitHub.
- Use a build script to generate the source package files.
- Upload the source package to launchpad.net, so it can be built and hosted on the Regolith
experimentaldepending on the level of change) PPA
- Test the package once it's been uploaded on a Regolith system.
- Once testing is complete, the package is promoted to
stableand then eventually
Basic Packages vs
Until recently, packaging was done manually in that no scripts were used. Recently, we've been moving to using the
gbp tool which provides some nice productivity enhancements when packaging with git repos. Branch names may differ based on if the package in question has been migrated yet.
- If a package contains the package source and the debian metadata, then
masterrepresents the development branch. The Ubuntu version associated with a changelog entry is always the oldest supported, currently
bionic. This is to comply with launchpad.net's package copy policy.
- If a package varies from one Ubuntu release to another, then branches are created for each required version, except for the most recent, which is
master. Example branches:
bionic eoan master
- If a package requires some github integration such that the package cannot be cleanly built on
master, then a branch
debianis used specifically for the package.
- In order to build packages locally, the debian build tools will need to installed. It is necessary to understand these tools, and how they work together to produce and verify a package. Read the guides here and install the software they specify.
- To push to a Regolith PPA, you will need to become an official contributor and have your keys added to the launchpad account to enable you to push updates. This is not necessary however to push to your own PPA. Check here to learn how to create your own PPA.
Add comment to i3 config
1. Checkout the
$ git clone https://github.com/regolith-linux/regolith-i3-gaps-config.git $ cd regolith-i3-gaps-config
2. Make a change:
$ echo "# Here is my comment at the end" >> config
3. Update the changelog to bump the version and describe your change:
This will load an editor and create a new changelog entry. Here is what I added, yours will differ based on identity and configuration:
regolith-i3-gaps-config (2.4.15-1) bionic; urgency=medium * Added comment to i3 config file. -- Regolith Linux <email@example.com> Sat, 30 May 2020 20:10:27 -0700
4. Commit and push the change to the git repository:
$ git commit -am "Added comment to i3 config file." $ git push origin
5. A shell script is used to build the source package for uploading to launchpad.net:
$ cd .. $ git clone https://github.com/regolith-linux/regolith-builder.git $ cd regolith-builder $ ./build.sh package-model-R1.4.2.json ppa:regolith-linux/ubuntu/unstable /tmp regolith-i3-gaps-config
After this script completes, the source package will be uploaded to launchpad.net for inclusion into the
Go to the launchpad.net PPA page to see the current status of the upload. It typically takes 10 - 30 minutes for a package update to complete.
Once packaging building completes successfully, the binary packages will be available for users to download during any automatic or manual update process.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.