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 g...@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 g...@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 g...@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>
