Each package in Maemo Leste uses a specific git-based workflow which makes it easy to track history and maintain in an easy way.
Taking the https://github.com/maemo-leste/libcal/ package as an example - a valid repository contains at least two git branches:
Ideally, the branches should have no difference, but sometimes this may vary. Your git repository should contain your code, and a debian directory - which contains the debian package build logic. The compat level of the package should be no less than 9 and preferably it should use debhelper.
Once you have your package ready and it builds locally on your Maemo Leste VM/device, there are just a couple more things to do to make it ready for building on Jenkins:
The git tag
In debian/changelog you should have your package version. It is very important to have a git tag that reflects this version so Jenkins and jenkins-debian-glue can figure out which revision to build.
Keep in mind that the git tag should only contain the upstream version and no package revisions or epochs, for example if we have:
libcal (0.3-2) unstable; urgency=medium
Our git tag would be 0.3, and not 0.3-2
Once tagged, push the tag to git origin.
Your debian directory should contain a file called gbp.conf with the following contents:
Once all this is in place, make sure that you have a maemo/$codename branch containing all this ready and pushed.
How you can build packages
Building a packages is easier than one might think, it requires roughly the following steps:
- . Access to a Devuan/Debian system (you can use a VM running Maemo Leste or a Device running Maemo Leste.
- . Source code of a package, obtain either via git or apt source <packagename>
- . Install build dependencies (run from source directory): sudo apt-get build-dep .
- . Build a package using dpkg-buildpackage -uc -b
You can now install the package you have just built with dpkg -i somename.deb
If you make changes to a package, please submit a pull request for the repository of that package, likely: https://github.com/maemo-leste/PACKAGENAME
For now, we will take care of updating tags and branches.
How packages end up in the repository
There are currently two repositories:
- The main repository: https://maedevu.maemo.org/leste
- The extras repository: https://maedevu.maemo.org/extras
The packages in the extras repository are not core, but useful applications nonetheless.
The codenames and an /etc/apt/sources.list file entry would look like the following:
deb https://maedevu.maemo.org/leste ascii main contrib non-free
deb https://maedevu.maemo.org/extras ascii main contrib non-free
Packages in this repository get build by Jenkins, to which a select group of people has access. (Parazyd, Wizzup, Spinal84)
How packages are built using Jenkins
Read only access to the http frontend: https://phoenix.maemo.org/ (write-access can be granted)
All packages are hosted on https://github.com/maemo-leste and a current list of all the packages in Jenkins can be found here:
Every repository has a branch for each release, for example:
- maemo/ascii - main branch for Devuan Ascii target
- maemo/ascii-devel - optional branch for Devuan Ascii with unstable/testing version
- maemo/beowulf - main branch for Devuan Beowulf version of the package
See Development/Branches for more information on the usual branches flow.
Maemo Leste Extras
If you wish to maintain your own package in Maemo Leste, you can apply a package at https://github.com/maemo-leste-extras/bugtracker Have a look at the README in that repository and open a ticket.
Consideration for HAM
For packages built for extras to appear correctly in Hildon Application Manager, be aware that Maemo packaging system
included a few enhancements that HAM assumes. The most important one is that your application will only appear in HAM if the
debian/control file has a correct
section clause as explained on the Packaging Wiki. This wiki page also explains how to have HAM show your application's icon. Note that having an icon showing in HAM is a separate issue from having an icon show up in the application list (Hildon Home). The latter is done through
.desktop files, while the former is done in