Source tarball could not be uploaded correctly in my PPA

Asked by Jasem Mutlaq on 2012-01-15

I have my packages in a bzr branch that is linked to an external SVN repository on SF. I made a build recipe and I'm using Debian Version: {debupstream}-0~{revno} where revno is the bzr branch revision number.

When using "Request Build(s)" initially, all works fine for building and uploading the source tarball, and binary packages..etc to my PPA. However, if I try to build again, I get "Could not upload correctly" error in my PPA:

https://code.launchpad.net/~mutlaqja/+recipe/libapogee-daily

With the following specific error:

DEBUG Considering changefile 18815/ubuntu/libapogee2_2.3-0~23~oneiric1_source.changes
DEBUG Finding fresh policy
INFO Processing upload libapogee2_2.3-0~23~oneiric1_source.changes
INFO Upload was rejected:
INFO File libapogee2_2.3-0~23~oneiric1.tar.gz already exists in INDI, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
INFO Files specified in DSC are broken or missing, skipping package unpack verification.
INFO Committing the transaction and any mails associated with this upload.

However, there were absolutely no changes in the source code. Could it be that each time launchpad creates the tarball the checksums are somehow different due to timestamp or something else?

Any ideas on how to fix this? or is this a bug?

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Jasem Mutlaq
Solved:
2012-01-20
Last query:
2012-01-20
Last reply:
2012-01-20
Stefano Rivera (stefanor) said : #1

You can't build the same version twice.

Jasem Mutlaq (mutlaqja) said : #2

Shouldn't launchpad then look into debian/changelog before starting the build process then? Why does it _only_ fail at the upload stage?

If I understand your situation correctly you have triggered another build without any change in the source. In that case your debian/changelog would still be accurate for the build, so you would expect the build to succeed (since it suceeded before).

However when uploading to the PPA, launchpad compares the debversion of your build to that of the packages already in the PPA and simply rejects the upload if it finds a package with that revision already in the PPA. That's why you see the error.

Why would you want to rebuild the package without any changes to the source code?

Jasem Mutlaq (mutlaqja) said : #4

I don't want to rebuild the package without source changes, however, when I select "Daily Build" in launchpad, I always get this upload error and the code doesn't necessary change every day. Therefore, I made all my packages "Built on Request".

So this might appear to be a problem of the "Daily Build" trying to build despite no changes in the source.

A new daily build should only be triggered if one of the 3 branches used by your recipe receives a push (otherwise it's a bug).

Since your package revision however only contains the revision of the 'main' branch lp:libapogee upload will fail whenever the build was triggered by one of the 2 nested branches. You can include their revisions in the revision number as well as detailed here: https://help.launchpad.net/Packaging/SourceBuilds/Recipes#Version_numbers_and_substitution_variables

LaƩrcio de Sousa (lbssousa) said : #6

I have the same problem with my PPA. I maintain several backports (quantal, precise, lucid, and even hardy) of a given same upstream version of my software, each of them with a proper recipe for daily builds. The quantal recipe often builds and uploads first with no problems, but the other backports fail to upload, because the orig.tar.gz generated by these recipes are not identical to the quantal-recipe one, as it should be, since its contents is the same. Perhaps there is some timestamp difference in gzip headers of the generated orig.tar.gz's.

The only way to succesfully build and upload all backports is converting them to native packages, but I don't like this workaround. Is there something else I can do? Could Launchpad solve this problem, e.g., using printine-tar to generate identical orig.tar.gz's?