[Pkg-privacy-maintainers] Packaging workflow onioncircuits

[Ulrike Uhlig]

Hi!

On 10.07.19 13:22, Sascha Steinbiss wrote:

> thanks for the constructive response!

Thanks for picking it up :)

>> I tried to update this package myself some days ago and noticed that
>> there seems to be a missing workflow between Tails and Debian packaging,
>> mainly the missing pristine-tar file.
> 
> I'm a big fan of pristine-tar branches (and the build automation
> infrastructure around it, e.g. 'gbp buildpackage --git-pristine-tar
> --git-pbuilder ...')  because I've had more than one situation where,
> when hacking on a bugfix, I had to recreate an upstream tarball from the
> (hopefully up-to-date) upstream branch, and then its hash was different
> from the one uploaded by the original maintainer for whatever reason
> (preferred compression algorithm/level, ...), leading to a rejected upload.
> I also try to avoid 'apt-get source' and the like and stick to git as
> much as possible. Hence, as a contributor, I am usually happy to find
> such a complete repository and I try to prepare mine in the same state
> for the next person :)

We are on the exact same page and I saw that this is what you did until
the 0.5.

>> The person who had prepared the new upstream version told me they
>> followed the instructions in the file called HACKING. I created a ticket
>> on the Tails bugtracker to document how to correctly create a new
>> upstream version: https://redmine.tails.boum.org/code/issues/16813
> 
> I noticed this but as far as I can see the info in that file deals with
> how to prepare a new upstream release rather than how to update the
> Debian packaging repository.

It does, hence I was wondering how you had handled this in the past.

I tried to do it using gbp import-orig, but there was always a tiny diff
- that I stopped investigating when I saw your upload. But maybe I'll
try again next time :)

>> I also had issues using gbp on that version of the package and I
>> wondered if you, Sascha, could document in debian/README.source what
>> your packaging workflow looks like, so that it can be followed more
>> easily by someone else. I'm happy to document it myself if you can give
>> pointers.
>> On a sidenore, I generally prefer using a signed git tags
>> rather than the tarball in [1]. 
> 
> I must admit that I have little experience with having (and trying to
> follow) all upstream commits in the upstream branch. In my practice, I
> have always treated the history of an upstream project as independent
> from the packaging, which is represented by the evolution of a series of
> upstream tarballs officially released somewhere -- preferably signed, of
> course.

Fair enough!

> As intrigeri pointed out, it indeed has a path formed by an initial
> OpenPGP signature starting a chain of hashes all the way down to the
> orig tarball (Tails-signed Release file ->  main/source/Sources listing
> e548bae169c2554c6c1cb604fc810959e5f14d480d5de7b0fd5d5dc1cce72110 as the
> SHA256 hash for onioncircuits_0.6.orig.tar.xz). Which matches in our case.
> But this was just a one-off import to make sure Tails and Debian use
> exactly the same upstream source. I wasn't suggesting to keep doing it
> this way in the future :)

Great!

What do you think about documenting your preferred way of updating that
package in debian/README.source?

Cheers!
Ulrike