40

(quote from chat)

Got a PPA on launchpad for source packages for an IRC bot project I'm associated with (since its all the intermediate packaging for the stuff between releases, it's classified as an "experimental" PPA). Question: I've already packaged the stuff for a lucid build. Any clue how I'd be able to create the same packaging, except package it for maverick, and put it up to the same PPA that I've put the lucid packaging to?

jokerdino
  • 41,762
Thomas Ward
  • 80,112

2 Answers2

42

Probably the easiest way is to simply copy the binaries on Launchpad:

  1. Go to your PPA and click on 'View package details':

    enter image description here

  2. Click on 'Copy packages':

    enter image description here

  3. Select the Lucid packages:

    enter image description here

  4. Select 'Maverick' for the series, and choose to 'copy existing binaries':

    enter image description here

  5. Click 'copy packages' and that's it!

Nathan Osman
  • 32,525
  • Thanks much. Your instructions were spot on. Thanks much for the quick response, too. – Thomas Ward Mar 13 '11 at 07:22
  • @Evil: No problem. Glad I could help! – Nathan Osman Mar 13 '11 at 07:23
  • 5
    NOTE FOR OTHER QUESTIONS THAT LINK TO HERE!!! Copying existing binaries DOES NOT ALWAYS WORK for programs that are destined for other versions of ubuntu! See my rkhunter PPA and the changelogs for the Lucid version to understand what I mean: https://launchpad.net/~trekcaptainusa-tw/+archive/rkhunter/+packages – Thomas Ward Dec 31 '11 at 00:19
  • @ThomasWard: Good point - it doesn't always work. – Nathan Osman Dec 31 '11 at 01:46
  • George, i mention it because of a more recent question i answered and had my answer accepted in for a multidistro package. Also, I have learned things from the MOTUs. :P – Thomas Ward Dec 31 '11 at 03:57
  • 1
    What will happen, if I put something like these in the changelog file: hello (2.6-0ubuntu1) lucid maverick natty; urgency=low ?. Will launchpad build it for all 3 distros? – Khurshid Alam Mar 14 '13 at 16:49
  • 2
    @KhurshidAlam Sorry for the super super late response. That will fail with an "Invalid Changelog", and as such, you have to specifically tag each separately when using a PPA with a different version. https://launchpad.net/~nginx/+archive/stable is a good example of this, because to make it build I have to add the distribution to the version so it builds correctly with all the different libraries. (I maintain the nginx team's ppas for now hence me using that as an example.) – Thomas Ward Jul 22 '13 at 00:42
  • thanks. The copying approach worked well for most of the packages in my ppa, but it failed for one. I then attempted to create a new package (for xenial) but it was rejected with an error message regarding .orig.tar.gz: Rejected: File octave-iso2mesh_1.9.5+ds.orig.tar.gz already exists in ..., but uploaded version has different contents. See more information about this error in ... Files specified in DSC are broken or missing, skipping package unpack verification. Is there a way to avoid this error when testing/revising the packaging files (assuming orig was never changed)? – FangQ Jul 07 '20 at 16:51
  • never mind. turned out the .orig.tar.gz files were different on the two distributions (not sure why). after copying .orig.tar.gz from one to another, the package now can be uploaded with any error. – FangQ Jul 07 '20 at 17:33
  • Seems like copy packages is no longer an option, I'm not sure I can find the copy/delete options anywhere as shown in the screenshot. – Mendhak Aug 03 '24 at 21:06
14

If copying the binaries for the package you're building does not work, you'll need to upload a source package for each distro version by editing the debian/changelog file.

How to Re-Package for Another Distro Version

  1. Edit the debian/changelog file in your source package directory
  2. Change both the version and target distribution to reflect which distro you are building for

    For example: nginx (1:1.4.1-0ubuntu1~preciseppa1) precise; urgency=low
  3. Re-build source package: debuild -S
  4. Upload .changes file to your PPA: dput ppa:teward/nginx-stable-testing ../nginx_1.4.1-0ubuntu1~preciseppa1_source.changes

If the build is successful then congratulations you've just built a package for that distro! If not, you'll have to check the build log on Launchpad and address any issues you find.

References:

Community
  • 1
TrinitronX
  • 3,404
  • This is what I do! :D The MOTUs (gods of the universe repository) explained this when I needed to do different builds for nginx and other programs in a PPA, and they helped resolve a lot of my issues. Thanks for posting this! :) – Thomas Ward Dec 16 '13 at 20:17
  • Yeah I figured this would be useful information to document and make available to new packagers, as there can be a steep learning curve to using all the debian packaging tools, PPA uploads, conventions, and debugging failed builds. – TrinitronX Dec 16 '13 at 20:24
  • Indeed. I'm not changing the accepted answer though, because at the time of this question, there was no need to worry about varying libraries available in the various versions of Ubuntu. With nginx or rkhunter or other packages I backport often, there's a huge dependencies issue to address (different depends: in the control file and such), so I always use programversion-1~RELEASE0 where ~RELEASE0 is always some number with the given release it's in.. Usually when I backport from Debian to Ubuntu that's the case :) – Thomas Ward Dec 16 '13 at 20:26
  • Yeah, dependencies are definitely a pain point for backporting ;-) I agree, the accepted answer should suffice in most cases, and for users of bazaar source control repos, using Launchpad's bzr-builder recipe looks attractive too. However, when it comes down to packages with many dependencies, sometimes you have to build a custom package for your target distro. – TrinitronX Dec 16 '13 at 20:33
  • And I backport nginx from Debian Unstable to Precise, Quantal, Raring, and Saucy (and Trusty in a PPA, but I also make sure Trusty, until Debian freeze, will have the latest from Debian merged in :P), for the NGINX team, but alas there are sometimes bugs which I can't fix and Debian has to deal with... this is why I have a good relationship with the Debian maintainers :) – Thomas Ward Dec 16 '13 at 20:34
  • @ThomasW. After looking at your Launchpad profile I'm pretty impressed at how active you are. Thanks for making the Open Source world a better place! ^_^ – TrinitronX Dec 16 '13 at 20:58
  • ^.^ Thanks for the compliment! I am pretty highly specialized in the actual stuff I work with, mostly nginx bugs and general triage duties per bugsquad/bugcontrol, but yeah, I try and do my part :) – Thomas Ward Dec 16 '13 at 21:31
  • Thanks for this. After following this advice I'm noticing: Package includes an .orig.tar.gz file although the debian revision suggests that it might not be required. Multiple uploads of the .orig.tar.gz may be rejected by the upload queue management software. Launchpad seems happy, but is it possible to avoid re-uploading the source tarball? – cheshirekow Oct 09 '18 at 21:01
  • @cheshirekow : Not quite sure about whether there is a way to avoid dput trying to upload orig.tar.gz each time. I figured this was just a warning, but maybe someone more familiar with the Debian packaging repos can answer? – TrinitronX Oct 22 '18 at 21:17
  • @cheshirekow If you just used debuild -S then it'll check if that version of the software is already in the repos - if not it'll force upload the .orig.tar.gz. You can ignore that warning though for the most part. It's useful to know though if you are packaging a different version of the software with the same version string if things mismatch though, 'cause then you know you either did something wrong or you are needing to rename your package to something else due to conflicts. – Thomas Ward Oct 12 '20 at 12:38