Skip to content
William Desportes edited this page Feb 22, 2020 · 7 revisions

Recipes

Recipes are the smarts behind your Release Management. They determine exactly which parts of which source code trees are brought in, and how packages are version controlled as they are pushed out into PPAs.

See the end of this page if you want to learn more.

the Default Recipe

The default recipe for the new Git baumgarr_head repo (once it was made the main repo) was:

# git-build-recipe format 0.4 deb-version {debupstream}-0~{revtime}
lp:nixnote2 master

Here is the Old refault recipe for when it was originally created as a Bazaar repo

# bzr-builder format 0.3 deb-version {debupstream}-0~{revno}
lp:~nixnote/nixnote2/baumgarr_head

This is an example of what you might be offered when you first create a recipe. The first line is the Debian Version Logic and the rest of the lines are the Branch Logic.

our Recipes

nixnote2-daily

With the current Git Recipe editing GUI you must enter the recipe as

# git-build-recipe format 0.4 deb-version {debversion}-0+{revno}+{revno:packaging}+{time}
https://git.launchpad.net/nixnote2 master
merge packaging https://git.launchpad.net/~nixnote/nixnote2/+git/packaging master

even though it will display it afterwards as

# git-build-recipe format 0.4 deb-version {debversion}-0+{revno}+{revno:packaging}+{time}
lp:nixnote2 master
merge packaging lp:~nixnote/nixnote2/+git/packaging master

This was the old recipe, now renamed to nixnote2-daily-old

# bzr-builder format 0.3 deb-version {debversion}-0+{revno}+{revno:packaging}+{time}
lp:nixnote2
merge packaging lp:~nixnote/nixnote2/packaging

Issue: dpkg-genchanges: warning: the current version (2.0-beta-0533ubuntu15.04.1) is earlier than the previous one (2.0-beta-4)

Branch Logic

The default

lp:~nixnote/nixnote2/baumgarr_head

did not include the correct control files in the correct locations

Forking the original project and adding a third line to copy the files to the correct location did not help

nest-part packaging lp:~nixnote/nixnote2/artemgy_head package_scripts/deb debian

as it gave a

Conflict adding id to debian/control. Unversioned existing file package_scripts/deb/control.

Adding other project's control files for previous nixnote versions did not help either, causing numerous errors

merge packaging lp:~matsubara/nixnote/packaging

As above, the Build Logic which finally gave the results we were looking for was

lp:nixnote2
merge packaging lp:~nixnote/nixnote2/packaging

potential Branch Improvements

  • can we automatically merge the debian/changelog from subfolder of upstream nixnote2 repo ?

Version Logic

The main justification for versioning should come from a new page on the rationale behind different versions, perhaps a "Release Policy".

Requirements

Our requirements for the Version Logic:

  • Depend on debian changelog exactly as it comes from upstream
  • keep full version from changelog
    • e.g. debversion = 2.0-beta-4 NOT debupstream = 2.0-beta
  • main repo version is critical
  • package version is helpful
  • Date may be helpful
  • avoid ~ tilde 'cheat' if possible

original default

{debupstream}-0~{revno}

current

{debversion}-0+{revno}+{revno:packaging}+{time}

potential Version improvements

  • move to format 0.4 to allow {git-commit} (if it shows upstream) and simpler {revdate}
  • can we loose superflous -0 ?
daily versus stable

Daily builds are simply one day after the other. Therefore I'm not sure that major OR minor version (or even alpha beta etc) is relevant!

Stable builds should be versioned as per developer release tags, for example https://github.com/baumgarr/nixnote2/tree/v2.0-beta7

Troubleshooting

Interpreting build logs

IGNORE: it would appear that you may safely ignore the following message in the logs

  • You have not informed bzr of your Launchpad ID
  • Perl locale issues

Learning more

recipe help

recipe samples