[pkg-go] Bug#1105153: Bug#1105153: gocryptfs: Salsa CI is failing

[Otto Kekäläinen]

Hi,

> > I don't see the need to change gbp.conf. The repo is configured to
> > contain debian/* files only, and whoever created it clearly
> > does not want to use pristine-tar,
>
> It was yours truly. I prefer such simplified layout to avoid needless
> complexity and overhead of GBP-style merged repo layout.

That is subjective. If a new maintainer is to check out that
repository and build it, I suspect they will struggle. Also as soon as
you run into upstream bugs and either fix them in Debian and want to
submit it upstream, or find that they are already fixed in upstream
main branch or a pending PR/MR and you want to cherry-pick them, you
can't use any git commands but need to do manual patch management.

That structure will also fail to build with the Go team CI. If you
look at https://salsa.debian.org/go-team/packages/gocryptfs/-/pipelines
you see that the CI actually *never passed*. The structure you now
have *does cause overhead* - it is just that you don't bear it
yourself.

Only time the CI passed was when Felix Lechner fixed the repo on
branch https://salsa.debian.org/go-team/packages/gocryptfs/-/tree/debian,
but seems that was then abandoned and now you have two 'head' branches
on the repo.

Anyway I assume you have your locally optimal workflow that you once
learnt, and are probably new keen to learn a new workflow, so I won't
spend more time on it nor on cleaning up of fixing your repo. I don't
want to own the "overhead" - you should as the repo layout owner take
care of maintaining it yourself so it is clean and aligned with what
you want.

> IMHO "origtargz" utility makes "pristine-tar" obsolete.

It downloads the tarball purely based on URL, without using any
verification / security features. As this is a security tool and the
maintainer understands supply-chain security, they over signed
tarballs at https://github.com/rfjakob/gocryptfs/releases/tag/v2.5.4.
If I were to maintain this package in Debian, I would definitely use
both pristine-tar and upstream signature verification. Your comment
assuming that origtargz, that has no security features whatsoever,
somehow obsoletes a tool specifically designed for supply-chain
security, makes it seem that the gap between your and my expectations
is wide, so I probably should just look away and not try to care about
this package.