Problem with pristine-tar (which tarball should I commit?)
Hello,
Me and Stéphane are taking over the maintenance of supervisor[0] and I
stumbled upon problems:
* there's no pristine-tar commit of the upstream release 3.3.1
* there was a NMU, so the last upload was 3.3.1-1.1
* 3.3.1-1.1 was not committed on the packaging repository
* we committed changes before making sure the git repo was up to date,
for the release 3.3.4
So I need to introduce the changes from 3.3.1-1.1 to the packaging
repository while keeping the commits we already made (for the 3.3.4-1
package that is being worked on).
If I clone the repository and do a gbp import-dsc of 3.3.1-1.1 it mess
up the repository because it will create the commits after the 3.3.4-1
ones in the master branch.
My plan of action was:
1) commit 3.3.1 to pristine-tar
2) commit the changes of 3.3.1-1.1 of master on the correct place,
rewriting git history[1]
3) confirm that both the tags debian/3.3.1-1 and debian/3.3.1-1.1
builds correclty
The main problem is on the first step, I described the whole plan in case
anybody has a different suggestion on how to fix this but nonetheless I
would like to at least understand what is going on with pristine-tar:
First plan was to import the github tarball of the 3.3.1 release:
wget https://github.com/Supervisor/supervisor/archive/3.3.1.tar.gz -O \
supervisor_3.3.1.orig.tar.gz
gbp clone git@salsa.debian.org:debian/supervisor.git
cd supervisor
git checkout pristine-tar
pristine-tar commit ../supervisor_3.3.1.orig.tar.gz
c9265954ea25e0b23ada7f613989d3d41d85c93a
git checkout debian/3.3.1-1
gbp buildpackage --git-builder=sbuild -A -v -d unstable
And I end up with:
dpkg-source: error: aborting due to unexpected upstream changes
With a list of files that were modified.
So this leads me to think: Ok, that is not the correct tarball used by
the previous maintainer, so it must be either the files on the
upstream branch (since I'm passing the commit hash of upstream/3.3.1
to pristine-tar) or the ones on the master branch (excluding the
debian dir):
gbp clone git@salsa.debian.org:debian/supervisor.git
cd supervisor
git checkout upstream/3.3.1
tar -zcvf ../supervisor_3.3.1.orig.tar.gz *
git checkout pristine-tar
pristine-tar commit ../supervisor_3.3.1.orig.tar.gz
c9265954ea25e0b23ada7f613989d3d41d85c93a
git checkout debian/3.3.1-1
gbp buildpackage --git-builder=sbuild -A -v -d unstable
Result:
gbp:error: Pristine-tar couldn't verify
"supervisor_3.3.1.orig.tar.gz": pristine-tar:
/tmp/build-area/supervisor_3.3.1.orig.tar.gz does not match stored
hash (expected 85eda4f053d2ef6c19a4b33fbf5c9fe7d8dfc24fabf7bc4067707ec841d6d30c,
got 454f532fae5a54363838fba42bc568f7b2fd0fd71d946b8c39d848a225d0da0f)
Ok, so this is strange, the sha256sum of the GH tarball is the second
one showed on the error, so this means that I should have committed
that tarball instead, and the error says "expected" from a POV where
it expects the upstream code[2] to be equal of the pristine-tar files
(and not the other way around), let's at least check the sha256sum of
the files on the master branch (excluding the debian dir):
gbp clone git@salsa.debian.org:debian/supervisor.git
cd supervisor
git checkout debian/3.3.1-1
tar --exclude='debian' -zcvf ../supervisor_3.3.1.orig.tar.gz *
sha256sum ../supervisor_3.3.1.orig.tar.gz
Result:
74cc1931e2ab8c90a7ff980c71f408a2f43be3449f927b2f724f78ea1feabbd1
../supervisor_3.3.1.orig.tar.gz
Which is again different of the sha256sum of the tarball I created
from the upstream/3.3.1 tag.
All of this makes me think that I'm missing something very crucial
here, the possibilities I can think are:
* I should not assume that the contents of upstream and master branch
should be the same (even when using 3.0 quilt sources format)
* I'm doing something wrong when generating the tarballs of the
upstream and master branch, I highly believe this is one of the
problems
* I should not assume that if the hash of a tarball being equal as the
one which Pristine-tar expects to is the correct one, because I
received that errors when committing the tarball from GH and it looks
like it's the one which pristine-tar doesn't complain of hash
mismatch.
I know that this a very long email, so I appreciate your attention, I
hope I described this in an understandable way.
I would be glad to receive either explanations on what I'm missing
here on the way things should work, the list of commands I should run
in order to fix the repository, or any pointers towards documentations
I should read to understand what is happening.
[0]Previous maintainer ack'ed, the repo is:
https://salsa.debian.org/debian/supervisor
[1]This should not be a problem since this is gonna be the first
release of the package under salsa and AFAIK we are the only ones
working on it, also, the changes of 3.3.1-1.1 should not break the
next commits since it only introduces a new patch:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870187
[2]Since both the tarballs I generated from the upstream and master
branch does not have the second hash showed on the error, where does
pristine-tar is getting that hash from?
Thanks,
--
Samuel Henrique <samueloph>
Reply to: