On Mon, Oct 15, 2018 at 05:02:51AM -0300, Samuel Henrique wrote:
> 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
No? It means you should delete the wrong tarball from /tmp/build-area.
> 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),
No?
"${tarball} does not match stored hash (expected ${stored_hash}, got ${tarball_hash})"
> 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
Here you are making a random tarball and checking its hash, I don't think
it's worth doing.
> 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.
Which is expected.
> 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)
They should be the same after removing debian/ from both.
> * I'm doing something wrong when generating the tarballs of the
> upstream and master branch, I highly believe this is one of the
> problems
You shouldn't generate them manually...
> * 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.
Umm.
--
WBR, wRAR
Attachment:
signature.asc
Description: PGP signature