-
Notifications
You must be signed in to change notification settings - Fork 3
Launchpad 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 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.
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)
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
- can we automatically merge the debian/changelog from subfolder of upstream nixnote2 repo ?
The main justification for versioning should come from a new page on the rationale behind different versions, perhaps a "Release Policy".
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
{debupstream}-0~{revno}
{debversion}-0+{revno}+{revno:packaging}+{time}
- move to format 0.4 to allow {git-commit} (if it shows upstream) and simpler {revdate}
- can we loose superflous -0 ?
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
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
-
matsubara used "deb-version {debupstream}-2~{revno}"
-
Novacut dailies uses "deb-version {debupstream}~bzr{revno}"
-
- mentions pros and cons of debian INSIDE main source versus OUTSIDE in SEPARATE source repo
- also has recommendations for tracking Ubuntu versions and using Apport crash debug reporting
- for dailies uses "deb-version {debupstream}~bzr{revno}"
- see also the Novacut release process with build categories defined
-
this is a more detailed packaging PPA
-
(what is there of use in ?) the Keepass2 announcement of PPA available
-
How GRASS defines their PPAs, with build definitions and recipes, and the procedure for coding and testing package changes