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

[Dmitry Smirnov]

On Tuesday, 13 May 2025 3:03:10 PM AEST Otto Kekäläinen wrote:
> That is subjective.

When comparing two different approaches to maintenance, is it really
that "subjective" to produce informed judgement about which one is
better?

My "subjective" conclusion is supported by decade of intense package
maintenance of broad range of Debian packages.


> If a new maintainer is to check out that
> repository and build it, I suspect they will struggle.

Only if they are incompetent and only can build a package with assistance
of GBP. Such maintainers typically don't know how to prepare NMU, and/or
fix a bug without access to git repository.

Actually, GBP repo layout have much greater surface for struggle. Problems
with GBP layout happen all the time and they are often difficult to fix.

What is there to struggle with non-GBP package build workflow?

  https://salsa.debian.org/onlyjob/notes/-/wikis/bp


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

Nonsense. There are simple methods to with with such situations, starting
with wget-ting patch directly from Github, or format-patch-ing from local
branch following upstream, or exporting patch from git GUI (e.g. "gitg").

Remember that "upstream" branch in GBP layout is often just redundant
import or tarball by "gbp import-orig".


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

You are confusing different issues. It "never passed" because repository
was in a mess, and I had no capacity to fix everything, working under
assumption that someone else still cares for the package.


> The structure you now have *does cause overhead* - it is just that
> you don't bear it yourself.

No. GBP repo layout cause greater overhead than my elegant, minimalistic
approach.

I shall be happy to switch CI to use my own Gitlab Runner infrastructure,
if you are concerned by overhead to Salsa's Runners.

(I'd like to think that my Runner relieves some overhead from Salsa, at
least in the projects configured to use it.)


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

Yes, there was an issue with GBP layout, that's why I did the work in 
"master" branch".


> Anyway I assume you have your locally optimal workflow that you once
> learnt, and are probably new keen to learn a new workflow,

This is ridiculous and even outrageous. I use GBP layout in teams where
it is appropriate, but I don't like it, because it creates redundant
overhead, and it is not suitable for sophisticated packages, MUT packages,
etc. 

Here is my incomplete overview of problems with GBP layout:

  https://salsa.debian.org/onlyjob/notes/-/wikis/no-gbp

Also let me remind you that I have worked on over 12 times(!) more packages
than you did, hence I know a fair bit about those things.

That "new workflow" is not always better as it comes with cost of added
complexity.


> so I won't spend more time on it nor on cleaning up of fixing your repo.

As you wish, but there is nothing to fix (apart from removal of redundant
"debian" branch"). Santiago kindly fixed CI so now the repo is in OK state.

You can have your "upstream" branch, or even push it to repo -- I don't
care because I don't use "upstream" branch at all, always building from
downloaded tarball.


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

I don't understand what "overhead" you are talking about...


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


Nonsense. "origtargz" uses various methods of obtaining tarball, including
generating it from repository. However numerous problems originate from
situation where orig-tarball generated from repo is not binary identical
to already uploaded one (or to actually released tarball, like in case when
"uptream" branch is broken, incorrectly tagged, tampered with, etc.)

To avoid such problems it is best to ignore "pristine-tar" and "upstream"
branches, and build from orig-tarball obtained from Debian mirrors
(from where "origtargz" conveniently fetches, when possible), or get
orig-tarball by "uscan" command (that "origtargz" invokes automatically),
using signature verification whenever it is codified in "debian/watch".


P.S. If you insist I can align with your preferences, as it is not all
that important to me how "gocryptfs" package repository is structured.
Since I can spare only so little time for it, I'd say adopt the package
if you care about it, having git repository layout of your preference,
and yours truly might occasionally come back with contributions that
don't disrupt established layout.

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
 -- Friedrich Nietzsche
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-go-maintainers/attachments/20250513/bb07774b/attachment.sig>