Diff for "PPA"

Not logged in - Log In / Register

Differences between revisions 1 and 8 (spanning 7 versions)
Revision 1 as of 2008-07-02 21:18:47
Size: 5522
Editor: 92-237-59-186
Comment:
Revision 8 as of 2008-08-01 13:48:29
Size: 12624
Editor: 92-237-59-186
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
'''DRAFT: this page is a work in progress. Please [[Feedback|seek further help]] or check the [[TitleIndex|wiki index]] for a complete page on this topic.''' ~- [[FrontPage|Launchpad Help]] > Personal Package Archives -~
Line 7: Line 8:
Ever individual and team registered in Launchpad gets their own apt repository. They're called Personal Package Archives; you'll probably see that shortened to PPA in most places.

Your PPA is an efficient and convenient way to distribute software to Ubuntu users. All you have to do is upload a source package and Launchpad will:

 * build binaries for x86, AMD64 and lpia architectures
 * host the binaries in your own apt repository
 * push updates to your users when you build new binaries.
 
Installing and uninstalling software from a PPA is just as easy for Ubuntu users as installing software from their operating system's primary archives. This makes it an ideal way to distribute beta versions, daily builds and other versions of your software for testing, without having to ask your testers to compile your software from source.

Personal and team PPAs work exactly the same, except that in the case of team PPAs then entire team has permission to upload to the archive.
With Launchpad's Personal Package Archives (PPA), you can build and publish binary Ubuntu packages for multiple architectures simply by uploading an Ubuntu source package to Launchpad. Every individual and team in Launchpad gets their own PPA.

Your PPA gives you:

 * An APT repository of up to 1 gigabyte for free software - see our [[PPATermsofUse|PPA terms of use]] for more detail.
 * Binary packages built for x86, AMD64 and LPIA architectures against Ubuntu.
 * A web front-end where Launchpad users can browse and search for your packages.

Before you create and use your PPA, you need to:

 * [[https://wiki.ubuntu.com/PackagingGuide|learn Ubuntu packaging]]
 * install dput - ```sudo apt-get install dput```
 * [[BecomingAnUbuntero|become an Ubuntero]] (i.e. you must sign the Ubuntu Community Code of Conduct)
 * have [[ImportingYourOpenPGPKey|imported your PGP key]] to your Launchpad account.


Installing and uninstalling software from a PPA is just as easy as installing software from Ubuntu's primary archive. This makes it an ideal way to distribute beta versions, daily builds and other versions of your software for testing, without having to ask your testers to compile your software from source.

Packages you publish in your PPA will remain there until you remove them, they're superceded by another package that you upload or the version of Ubuntu against which they're built becomes obsolete.

== Activating a PPA ==

Before you can start using a PPA, whether it's your own or it belongs to a team, you need to activate it on your [[https://launchpad.net/people/+me/|profile page]] or the team's overview page.

You can only activate your PPA if you have [[BecomingAnUbuntero|signed]] the Ubuntu code of conduct.
Line 21: Line 36:
PPAs work just like normal Ubuntu archives. You can install software in the usual way - for example, through ```apt-get``` or ```synaptic``` - and whenever there's an update Ubuntu will prompt you to install it.

/!\ '''Important:''' when you install software from a PPA, Ubuntu will warn you that it is unsigned. For more on why packages in PPAs aren't signed, [[PPA/FAQs#unsigned|see the PPA FAQs]].
PPAs work like normal Ubuntu archives. You can install software in the usual way - for example, through ```apt-get``` or ```synaptic``` - and whenever there's an update Ubuntu will prompt you to install it.

'''Important:''' when you install software from a PPA, Ubuntu will warn you that it is unsigned. PPA packages are unsigned because they are not official Ubuntu packages. You should make sure that you're confident in the PPA owner's abilities before you install their packages.
Line 27: Line 42:
To install packages from a PPA, you need to tell Ubuntu where to find it. You do this by giving Ubuntu the PPA's URL, which you can find on the PPA's Launchpad page. To install packages from a PPA, you need to tell Ubuntu where to find it. You do this by giving Ubuntu the PPA's URL, which you can find on the PPA's overview page.
Line 42: Line 57:
Before you start using your PPA to distribute software, you need to be familiar with building .deb source packages.
 

 and host them in your own apt repository.




 When upload an updated version of your package, your users' operating systems will prompt them to upgrade.


handles the rest, including:

 * building binaries for x86, AMD64 and lpia
 *
 
 
 
 

Using your Personal Package Archive (PPA), you can build and distribute software packages for use in Ubuntu and Debian.

 * build packages for x86, AMD64 and lpia architectures
 * automatically push updates to users
 *



Use the first two paragraphs to summarise all the important points about this article.

Tell the reader if this is the information they need as soon as possible.

= Instructional text =

Where appropriate, use step by step instructions:

'''Step 1:''' Give concise and unambiguous instructions.

'''Step 2:''' Try not to state the obvious, unless you're writing for a novice user.

{i} '''Note:''' Highlight important information with a note.

'''Step 3:''' Use a well cropped screen shot if it will help orient the reader. Don't let the screen shot replace instructional text: not everyone can see your screen shot. Don't worry about borders or annotation for small, cropped screen shots such as this.

{{attachment:screen-shot.png}}

{i} '''Warning:''' If you're about to tell the reader to delete or otherwise change something that would be hard to restore, warn them.


== Full screen shots ==

||<tablestyle="float:right; font-size: 0.8em; width:30%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;">{{attachment:proj-announce.png}}||
||<style="text-align: center;">'''Describe the screen shot here'''||

Some screen shots will be better placed to the right of your text. As they're not placed directly below the text that they support, use a border and short description.

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aliquam sagittis. Aliquam eros dui, scelerisque id, consequat in, accumsan vitae, pede. Suspendisse neque ligula, scelerisque ac, mattis ut, aliquam quis, odio.

Proin nunc nisi, fringilla ac, congue ac, luctus eu, lacus. Maecenas ac purus. Cras felis metus, ultricies non, euismod ac, accumsan eleifend, leo. Quisque imperdiet tempus tellus.

Ut euismod, diam nec adipiscing interdum, tortor orci fringilla nisi, vel blandit erat magna at nisi. Fusce hendrerit odio non metus. Mauris nisl massa, dapibus id, feugiat quis, blandit a, quam. Integer tincidunt feugiat nunc. Curabitur iaculis egestas elit. Nam imperdiet suscipit odio.
Before you start using your PPA to distribute software, you need to be familiar with building .deb source packages for Ubuntu. The best place to learn how to package for Ubuntu is the [[https://wiki.ubuntu.com/PackagingGuide|Ubuntu packaging guide]].

There are a couple of aspects of PPAs that work slightly differently to standard Ubuntu packages:'''versioning''' and '''dependencies'''.

Let's take a look at each in detail.

<<Anchor(versioning)>>
== Versioning ==

Ubuntu package names are suffixed by the version number of the package. This allows Ubuntu to distinguish newer packages from older ones and so remain up to date.

If you're creating an alternative version of a package already available in Ubuntu's repositories, you should ensure that:

 * your package supersedes the official Ubuntu version
 * future Ubuntu versions will supersede your package.
 
To do this, increase the Ubuntu version number and add a suffix of ~ppa''n'' (where ''n'' is your package's revision number).

For example: you're creating an experimental version of the ``myapp_1.0.1`` package. Your PPA package would be named ``myapp_1.0.2~ppa1``.

Here, the tilde knocks the precedence of the package down to below whatever is in front of it. So, for now, this package counts as being a higher version number than ``myapp_1.0.1`` but when Ubuntu releases ``myapp_1.0.2`` that will supersede your PPA version.

== Dependencies ==

Launchpad satisfies your package's {{{Build-Depends}}} using:

 * the most recent versions of the packages in the PPA you're uploading to
 * all sections of the primary Ubuntu archive - i.e. main, restricted, universe and multiverse
 * '''optionally:''' other PPAs in Launchpad.
 
'''Note:''' If you're already familiar with uploading to the Ubuntu primary archive, you should note that PPA builds do not have any build dependency restrictions, unlike a build in the primary Ubuntu archive. If you want to build the same package in the primary Ubuntu archive at a later point you may need to revise the package's component and/or pocket.

=== Depending on other PPAs ===

If you want Launchpad to satisfy your package dependencies using one or more other PPAs, follow the ```Edit dependencies``` link on [[https://launchpad.net/people/+me/+archive|your PPA]] or the team's overview page.

== Building ==

Which ```debuild``` options you use depends on whether or not you're creating an alternative version of a package already in the Ubuntu repositories.

 * '''Alternative version:''' ```debuild -S -sd```
 * '''New package with no orig.tar.gz in Ubuntu's repositories:''' ```debuild -S -sa```

'''Note:''' If you get the error ```clearsign failed: secret key not available``` when signing the changes file, use an additional option ```-k[key_id]``` when calling debuild. Use ```gpg --list-keys``` to get the key ID. Look for a line like "```pub 12345/12ABCDEF```"; the part after the slash is the key ID.

== Uploading ==

```Dput``` is the tool you use to upload your source package to Launchpad.

First, you need to tell ``dput`` where to send your package and by what method. To do that, edit ```~/.dput.cf``` to look like this:

{{{
[my-ppa]
fqdn = ppa.launchpad.net
method = ftp
incoming = ~your-launchpad-id/ubuntu/
login = anonymous
allow_unsigned_uploads = 0
}}}

Change the first line to whatever name you want to use to refer to the source package, while retaining the square brackets.

If you're uploading to a team PPA, change the ```~your-launchpad-id``` to your team's Launchpad name. As you might expect, you must be a member of the team before you can upload to its PPA.

Next, open a terminal and enter the following:

{{{
$ dput my-ppa P_V_source.changes
}}}

Replace ```P``` with the package name and ```V``` with the [[PPA#versioning|version]] number.

=== Possible upload errors ===

Once you've made the upload, Launchpad will send you a success or failure notice by email. You can check the status of your build by visiting on [[https://launchpad.net/people/+me/+archive/+builds?build_state=all&build_text=|your PPA's build status page]].

There are a couple of common errors to look out for:

 * If you get error when signing the changes file (```clearsign failed: secret key not available```), pass an additional option ```-k[key_id]``` to debuild. You can use ```gpg --list-keys``` to get the key ID. Look for line similar to "```pub 12345/12ABCDEF```"; the key is the alphanumeric section after the forward slash.
 
 * Your upload may appear to succeed, followed by an email with the following:
 
 {{{
Rejected:
Signer has no upload rights at all to this distribution.
Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state.
 }}}
 
 This means that you forgot to specify your PPA's name on the command-line (that is, the "my-ppa" part) and dput sent your upload to the primary Ubuntu archive, for which you don't have authorisation. You can disable that behaviour by adding these lines to your ~/.dput.cf:

{{{
[DEFAULT]
default_host_main = notspecified

[notspecified]
fqdn = SPECIFY.A.PPA.NAME
incoming = .
}}}

Now, if you omit the PPA name you'll immediately get an error.
 
=== Using packages from other distributions ===

You can use your PPA to build sources from other distributions that use ```.deb``` packages.

Upload to ```~<lp_name>/ubuntu/<suite>``` and the suite you specify will override the suite named in the upload changelog. You can upload a source from any Debian-compatible distribution straight to your PPA with no changes required.

'''Important:''' Although Launchpad will attempt to build the package, it may not be able to meet all of the dependencies of a source created for another a distribution.
 
 
= Copying packages =

You can copy packages from other PPAs into any PPA that you can upload to. You also have the option of copying packages between distro-series (i.e different distribution releases).

For example: take a look at the [[https://launchpad.net/~ubuntu-mobile/+archive/+copy-packages|Ubuntu Mobile team's PPA copy packages]] page.

Here you can:

 * select one or more sources to copy
 * select the destination PPA - you must have upload permission for that archive
 * specifiy the destination series
 * choose whether or not to also copy the related binary package.

As soon as you request the copy, the source will be listed in your PPA with details of it origin. However, it can take up to twenty minutes for the files to actually appear in your archive.

If you only copy the source, the corresponding build records are created in the destination PPA immediately.

= Frequently asked questions =


'''What limits apply to the PPA service?'''<<BR>>
Other than the expectation that packages in your PPA are free software, we do ask that you not abuse the build system with unnecessary builds or automated uploads of large numbers of packages. We will monitor the total amount of build time per user and ask folks to be reasonable in their use of the shared resources in the PPA pool. Developers and teams each start with 1 gigabyte of storage space freely available in their PPA's for source and binary packages. We will not accept uploads of packages that are unmodified from their original source in Ubuntu or Debian, only packages that include your own changes. We ask that people include useful changelogs for each package so that users and other developers can understand what new features they are exploring in their work. Read the [[PPATermsofUse|PPA Terms of Use]] for more information.

'''How many users can download packages from my PPA?'''<<BR>>
There are no limits on the number of users you can point at your PPA. We would encourage you to build communities of users and testers around your PPA, and there are no bandwidth restrictions on downloads from any PPA.

'''How many PPAs can I have?'''<<BR>>
Each user and team in Launchpad can have a single public PPA. If you want to have different versions of the same package, testing different features or focused on different use cases, then we would encourage you to create a new team and use the PPA for that team. That way, for example, you can have a team of people interested in "server" issues that has one version of the Apache package, and another interested in "workstation" issues that has a different version of the same package, each in a different PPA. Please don't abuse this capability!

'''Why are only X86, AMD64 and LPIA architectures supported?'''<<BR>>
We use the Xen virtualisation system for security during the build process, ensuring that each build has a clean build environment and different developers cannot impact on one another's builds accidentally. This technology is only available for these architectures.

||<tablestyle="border: 0; width: 100%;"> ~-[[Translations/Groups|< Translation groups]] -~ ||


Launchpad Help > Personal Package Archives

Overview

With Launchpad's Personal Package Archives (PPA), you can build and publish binary Ubuntu packages for multiple architectures simply by uploading an Ubuntu source package to Launchpad. Every individual and team in Launchpad gets their own PPA.

Your PPA gives you:

  • An APT repository of up to 1 gigabyte for free software - see our PPA terms of use for more detail.

  • Binary packages built for x86, AMD64 and LPIA architectures against Ubuntu.
  • A web front-end where Launchpad users can browse and search for your packages.

Before you create and use your PPA, you need to:

Installing and uninstalling software from a PPA is just as easy as installing software from Ubuntu's primary archive. This makes it an ideal way to distribute beta versions, daily builds and other versions of your software for testing, without having to ask your testers to compile your software from source.

Packages you publish in your PPA will remain there until you remove them, they're superceded by another package that you upload or the version of Ubuntu against which they're built becomes obsolete.

Activating a PPA

Before you can start using a PPA, whether it's your own or it belongs to a team, you need to activate it on your profile page or the team's overview page.

You can only activate your PPA if you have signed the Ubuntu code of conduct.

Installing software from a PPA

PPAs work like normal Ubuntu archives. You can install software in the usual way - for example, through apt-get or synaptic - and whenever there's an update Ubuntu will prompt you to install it.

Important: when you install software from a PPA, Ubuntu will warn you that it is unsigned. PPA packages are unsigned because they are not official Ubuntu packages. You should make sure that you're confident in the PPA owner's abilities before you install their packages.

Adding a PPA to your Ubuntu repositories

To install packages from a PPA, you need to tell Ubuntu where to find it. You do this by giving Ubuntu the PPA's URL, which you can find on the PPA's overview page.

Let's take a look at the AWN Testing team's PPA as an example. If you're using the most recent development version of Ubuntu, all you need do is copy these lines in the apt sources.list entries section of the page. For example:

deb http://ppa.launchpad.net/awn-testing/ubuntu intrepid main
deb-src http://ppa.launchpad.net/awn-testing/ubuntu intrepid main

If, like most people, you're using another version of Ubuntu - such as the most recent stable version - then you need to select it from the drop-down box. That'll automatically update the URLs you need to copy.

Take a look at the Ubuntu guide to adding extra software repositories to find out how to add those URLs to your local Ubuntu system.

Building your source package

Before you start using your PPA to distribute software, you need to be familiar with building .deb source packages for Ubuntu. The best place to learn how to package for Ubuntu is the Ubuntu packaging guide.

There are a couple of aspects of PPAs that work slightly differently to standard Ubuntu packages:versioning and dependencies.

Let's take a look at each in detail.

Versioning

Ubuntu package names are suffixed by the version number of the package. This allows Ubuntu to distinguish newer packages from older ones and so remain up to date.

If you're creating an alternative version of a package already available in Ubuntu's repositories, you should ensure that:

  • your package supersedes the official Ubuntu version
  • future Ubuntu versions will supersede your package.

To do this, increase the Ubuntu version number and add a suffix of ~ppan (where n is your package's revision number).

For example: you're creating an experimental version of the myapp_1.0.1 package. Your PPA package would be named myapp_1.0.2~ppa1.

Here, the tilde knocks the precedence of the package down to below whatever is in front of it. So, for now, this package counts as being a higher version number than myapp_1.0.1 but when Ubuntu releases myapp_1.0.2 that will supersede your PPA version.

Dependencies

Launchpad satisfies your package's Build-Depends using:

  • the most recent versions of the packages in the PPA you're uploading to
  • all sections of the primary Ubuntu archive - i.e. main, restricted, universe and multiverse
  • optionally: other PPAs in Launchpad.

Note: If you're already familiar with uploading to the Ubuntu primary archive, you should note that PPA builds do not have any build dependency restrictions, unlike a build in the primary Ubuntu archive. If you want to build the same package in the primary Ubuntu archive at a later point you may need to revise the package's component and/or pocket.

Depending on other PPAs

If you want Launchpad to satisfy your package dependencies using one or more other PPAs, follow the Edit dependencies link on your PPA or the team's overview page.

Building

Which debuild options you use depends on whether or not you're creating an alternative version of a package already in the Ubuntu repositories.

  • Alternative version: debuild -S -sd

  • New package with no orig.tar.gz in Ubuntu's repositories: debuild -S -sa

Note: If you get the error clearsign failed: secret key not available when signing the changes file, use an additional option -k[key_id] when calling debuild. Use gpg --list-keys to get the key ID. Look for a line like "pub 12345/12ABCDEF"; the part after the slash is the key ID.

Uploading

Dput is the tool you use to upload your source package to Launchpad.

First, you need to tell dput where to send your package and by what method. To do that, edit ~/.dput.cf to look like this:

[my-ppa]
fqdn = ppa.launchpad.net
method = ftp
incoming = ~your-launchpad-id/ubuntu/
login = anonymous
allow_unsigned_uploads = 0

Change the first line to whatever name you want to use to refer to the source package, while retaining the square brackets.

If you're uploading to a team PPA, change the ~your-launchpad-id to your team's Launchpad name. As you might expect, you must be a member of the team before you can upload to its PPA.

Next, open a terminal and enter the following:

$  dput my-ppa P_V_source.changes

Replace P with the package name and V with the version number.

Possible upload errors

Once you've made the upload, Launchpad will send you a success or failure notice by email. You can check the status of your build by visiting on your PPA's build status page.

There are a couple of common errors to look out for:

  • If you get error when signing the changes file (clearsign failed: secret key not available), pass an additional option -k[key_id] to debuild. You can use gpg --list-keys to get the key ID. Look for line similar to "pub 12345/12ABCDEF"; the key is the alphanumeric section after the forward slash.

  • Your upload may appear to succeed, followed by an email with the following:
    Rejected:
    Signer has no upload rights at all to this distribution.
    Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state.
    This means that you forgot to specify your PPA's name on the command-line (that is, the "my-ppa" part) and dput sent your upload to the primary Ubuntu archive, for which you don't have authorisation. You can disable that behaviour by adding these lines to your ~/.dput.cf:

[DEFAULT]
default_host_main = notspecified

[notspecified]
fqdn = SPECIFY.A.PPA.NAME
incoming = .

Now, if you omit the PPA name you'll immediately get an error.

Using packages from other distributions

You can use your PPA to build sources from other distributions that use .deb packages.

Upload to ~<lp_name>/ubuntu/<suite> and the suite you specify will override the suite named in the upload changelog. You can upload a source from any Debian-compatible distribution straight to your PPA with no changes required.

Important: Although Launchpad will attempt to build the package, it may not be able to meet all of the dependencies of a source created for another a distribution.

Copying packages

You can copy packages from other PPAs into any PPA that you can upload to. You also have the option of copying packages between distro-series (i.e different distribution releases).

For example: take a look at the Ubuntu Mobile team's PPA copy packages page.

Here you can:

  • select one or more sources to copy
  • select the destination PPA - you must have upload permission for that archive
  • specifiy the destination series
  • choose whether or not to also copy the related binary package.

As soon as you request the copy, the source will be listed in your PPA with details of it origin. However, it can take up to twenty minutes for the files to actually appear in your archive.

If you only copy the source, the corresponding build records are created in the destination PPA immediately.

Frequently asked questions

What limits apply to the PPA service?
Other than the expectation that packages in your PPA are free software, we do ask that you not abuse the build system with unnecessary builds or automated uploads of large numbers of packages. We will monitor the total amount of build time per user and ask folks to be reasonable in their use of the shared resources in the PPA pool. Developers and teams each start with 1 gigabyte of storage space freely available in their PPA's for source and binary packages. We will not accept uploads of packages that are unmodified from their original source in Ubuntu or Debian, only packages that include your own changes. We ask that people include useful changelogs for each package so that users and other developers can understand what new features they are exploring in their work. Read the PPA Terms of Use for more information.

How many users can download packages from my PPA?
There are no limits on the number of users you can point at your PPA. We would encourage you to build communities of users and testers around your PPA, and there are no bandwidth restrictions on downloads from any PPA.

How many PPAs can I have?
Each user and team in Launchpad can have a single public PPA. If you want to have different versions of the same package, testing different features or focused on different use cases, then we would encourage you to create a new team and use the PPA for that team. That way, for example, you can have a team of people interested in "server" issues that has one version of the Apache package, and another interested in "workstation" issues that has a different version of the same package, each in a different PPA. Please don't abuse this capability!

Why are only X86, AMD64 and LPIA architectures supported?
We use the Xen virtualisation system for security during the build process, ensuring that each build has a clean build environment and different developers cannot impact on one another's builds accidentally. This technology is only available for these architectures.

< Translation groups

PPA (last edited 2008-09-02 11:29:17 by 92-237-59-186)