[Pkg-privacy-maintainers] Packaging workflow onioncircuits

[Sascha Steinbiss]

Hi Ulrike and all,

thanks for the constructive response!

>> I think this is easily fixed. I will address this in an upcoming upload.
> 
> Nice!

Done!

>> BTW, is it intended to also have Tails releases in the Debian git repo
>> with upstream versions newer than the one in Debian? If so, I would be
>> glad if you could make sure to also include a pristine-tar tarball for
>> the new upstream version so we don't work off different upstream
>> sources. I have now imported the orig tarball from Tails [1] to make
>> sure we're in sync for now. Thanks!
> 
> 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 :)

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

> 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.
I can see that signed commits provide a more immediate way of
authenticating but I don't know off the top of my head how to properly
handle updates there. What I usually do for upstream updates is:

$ git checkout master
$ uscan --verbose    # get new upstream source according to watchfile
$ gbp import-orig --pristine-tar ../<new_upstream.tar.gz>
$ dch -i             # bump version in d/changelog
$ gbp buildpackage --git-pbuilder --git-pristine-tar --git-ignore-new
-uc -us --git-pbuilder-options=--source-only-changes  # build!
$ ....               # QA, reprotest, etc.

Note that, in this case, second step (uscan) transparently creates an
orig tarball from the tags in the upstream Git repository, see d/watch.

I guess when using an upstream branch tracking the upstream repo, I
would have to manually pull changes into the upstream branch from the
upstream repo and tag the relevant signed release commit with
"upstream/<upstream_version>" for git-buildpackage to pick it up. Then
merge this tag into master and continue from step four above. Correct?
Do you know of any automation that might help? Of course, I would be
happy to learn something new and do things in a way that fits with the
rest of the team.

> Do we agree that this tarball has no signature?

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 :)

Cheers
Sascha

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-privacy-maintainers/attachments/20190710/7187c52e/attachment.sig>