How to maintain the Ubuntu Studio Packages
This section is a step by step description on how to make changes to a Ubuntu Studio package and publish it.
Ubuntu Studio package source can be found in one of two places:
- Launchpad (where our original sources are kept)
- Ubuntu archive (where the packages are built, and becomes installable)
Source at launchpad
Let's look at a typical Ubuntu Studio original package, using ubuntustudio-default-settings as an example.
Typically all Ubuntu Studio source packages belong to a launchpad project with the same name as the source package. In the case with the package ubuntustudio-default-settings, the project page is launchpad.net/ubuntustudio-default-settings, and the source can be found at code.launchpad.net/ubuntustudio-default-settings.
There may be more than one source repository for the package. The one under active development is the one with the shorthand lp:<projectname>. The real name for the package with that shorhand is trunk, which you can see from this full url to the trunk branch for ubuntustudio-default-settings: https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio-default-settings/trunk.
Repository naming for bzr branches
The development branch: trunk
There's always at least one branch for each project/package called trunk. This is the branch which is under active development, and will always stay that way. So, if you ever create a new original Ubuntu Studio package, create a project for it with the same name as the package, and if you create a bzr repository you name it trunk. If it's a git repository, you may use a different naming scheme.
Stable Release branches
There's no need to create branches other than trunk usually. The situation where this might be needed is when you need to fix a bug in a stable release package, but for some reason you are not able to just build and upload the current development branch. When that happens, you'll can create a new branch which is based on the stable release code - not the trunk branch.
Creating a branch for it under the project will allow other team members to further make changes to the same source, so doing this is only valuable when many people work on the same source. Else, you can just create a personal branch, do the bugfix, and then do a merge request (but this is under the topic bug fixing, so not further explained here).
If you need to create a new branch of the stable release of a package, this is how you do it (using ubuntustudio-default-settings as an example package):
pull-lp-source ubuntustudio-default-settings trusty
Create a new branch in launchpad for it. Name it using either the codename (i.e. trusty), or the release number (14.04). For example:
bzr push lp:~ubuntustudio-dev/ubuntustudio-default-settings/14.04
Making Changes to a Package
Different packages need different kind of treatment. But, simply put, there are two kinds of packages:
- meta packages
Meta Package Maintenance
The ubuntustudio-meta package is special. The source is kept in bzr which you can obtain with:
bzr branch lp:ubuntustudio-meta
However, most of the time, we only need to update the metapackage with the latest seeded packages (using the ./update script), and therefore we start with the last version that was uploaded to the archive instead. Normally, it would only be necessary to use the bzr repository to make a change to the metapackage framework, or to change the way the meta's are packaged. If you do this, you will need to be careful to check the archive version for changes (other than the list of seeded packages), so that the bzr branch can be brought into sync.
So instead, pull the source for the development release with:
In the rare cases you need to make changes to a released version of Ubuntu Studio, you need to also specify the release:
pull-lp-source ubuntustudio-meta xenial
Enter the downloaded source directory:
Then run the "update" script to update the seed files based on the latest seeds:
To run the above command, you will need to have the ""germinate"" package installed. This script downloads the latest package files from the archive, checks out the bzr repository for the seeds, and downloads relevant packages from the archive in order to update the seed files for all architectures (e.g. i386). The script also updates the Debian changelog with a new entry to list the changes to seeded packages.
Next, finalise the changelog. Specify the correct distribution, and remember to close any bugs against the metapackages with an (LP: #12345) entry against the relevant change entry.
dch -r -D yakkety
Then build the package locally:
This will rebuild all of the debian/control files for each binary meta-package (e.g. ubuntustudio-audio), so that the binary meta-packages depend/recommend all of the right Ubuntu Studio packages.
At this point, it is a good idea to do a "difference" check with the last version to see that the changes look sensible:
cd .. debdiff ubuntustudio-meta_0.155.dsc ubuntustudio-meta_0.156.dsc | less
If everything looks fine, it is time to build the final version, and upload it to a ppa ready for a test install:
cd ubuntustudio-meta-0.156 debuild -S cd .. dput ppa:ubuntustudio-dev/dev-testing ubuntustudio-meta_0.156_source.changes
This builds a source only version of the package, and the binaries will be built within the ppa. This may take some time if the build machines are busy. If you are not a member of the Ubuntu Studio Development Team, you can upload to your own ppa instead.
Once the ppa has successfully build the metapackage, fire up a machine (a virtual one will be fine) with the current Ubuntu Studio development version. Make sure the machine is up to date, and then add the testing ppa:
sudo add-apt-repository ppa:ubuntustudio-dev/dev-testing sudo apt-get update
This should find the new version of the metapackages to be tested, so that they will be installed with a ""sudo apt-get upgrade"" command.
Assuming it installs fine, then if you have upload rights, the *.changes file can be uploaded as normal. If you need sponsorship, then you should attach a debdiff between the previous version and this one to a bug in Launchpad, and subscribe the sponsorship team to the bug.
The debdiff can be generated by:
cd .. debdiff ubuntustudio-meta_0.155.dsc ubuntustudio-meta_0.156.dsc > ubuntustudio-meta.debdiff
bzr, debian build tools, uploading...