On Tuesday, 13 May 2025 8:49:12 AM AEST Santiago Vila wrote:

Ok, I've configured CI/CD in salsa to use debian/salsa-ci.yml,
and then I've made a commit which removes gitlab-ci.yml, as
it was not working.

Now the pipeline is all green.

Thank you very much for your help.

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.

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

and Salsa CI seems to be smart enough that it can build the package now.

This is new. Formerly Salsa CI could not build packages from repositories
that contain debian/* files only.

Dmitry: I'm therefore closing this bug. If you still want to use
the old test-the-archive, please reopen and make sure that it works.

All good, thanks. For packages that I maintain regularly I use my own
CI pipline that runs on my own Gitlab Runner (which runs on my hardware).

When I first uploaded gocryptfs I did not touch existing "gitlab-ci.yml" because I've thought that it would be a one-time upload... Since nobody
did any work on gocrypfs in a while, I later found myself working on it
again, but I had no capacity to adjust CI properly.

--
Best wishes,
Dmitry Smirnov
GPG key : 4096R/52B6BBD953968D1B

---

Tyranny is always better organized than freedom.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEULx8+TnSDCcqawZWUra72VOWjRsFAmgizO8ACgkQUra72VOW jRuOJA/+POi5x+Ai0K+jPmtTr9LihwHvdahs0QLmNa7octkN3vWxkAfEO5iPA7XI KFC4FhHACO9FyFcKl1zxtAFNTPXOiUTkTZPXvZSUqrnW1d00aC0TnwiGmDT7VzWM /leSPWwstGMU6cf+CrgVjNvxDlruUZDeeEUTCNCFZTLims18tg8zxne1aJfEtJop soZQ/jAsSqpcH1gEcF3apKAjkQMOJFZUuQQ9h7HAnXfanM0wjJOoqfu6QxCsGQ11 HjArAKnaQw34APTfW0hhiKfNHr+wZ685xCeEU5V3ri7+aMUOAFuy3teX1IJi63RE O2Zmqz8YHQ084ibJWDlRsr0Vu9xnKKM5fMnOKQye0WaofPARE+IAD4hSbWoMRF7E JAHFfbPhTJTvJaLaFdm3fWugzmvgfPnCFwKSiozKsspzU989o0gZ8KUNCPJYAKlp 04vbgUhP8JRChlZXS+J5LE6MEmO1brGXiK+/olKAmZIiFiZcup4qOn/C9dAIIQGX WW85FLF11htXpiaFysfjNL4vL9MDJ6cR2qd7JKn55R+GjLDteD/x9u2bp7kVLi2F F3hJ1Mpf2+JEL3WooPqv6lh3RZWW+84fUWJcq0Ml0RpFCKUOXlUVWgechw7P8AtS ET4E/qwNB2qoSvf+WfymxC6JJt6f0aDiOXJIvvRQmyqvHtYZC1Y=
=PTl6
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: 1105153@bugs.debian.org
Copy: sanvila@debian.org (Santiago Vila)

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEULx8+TnSDCcqawZWUra72VOWjRsFAmgjF9kACgkQUra72VOW jRvv+RAAi9e67t5n+OWyIo4Cwn2blfpodzKEawdiBOc82vFlNeqzr7RnTL7uhA7b D8gZhIq9ImXP+H0cGH7JrZHhfl+UweeYYcebTXbRY+AOAP0pCWW5b3QK2ruZdBSq T1CbngbfWAW1DMtNnEXd7SBx4PtqkYJ7Vt3KIolIOjxNKCxU7AxxJry7wjYDYkjD 35UnhysZHOBgj/3GSCjgnYtY/VR4Y6k/F3FlrIrfMIDtZ8fo3uHSirFVBYwb3cLX 8tTjfL917vytivxUAFjOEfkykGsUSkjokMJj291ZiaCzXPMxSubLydKcUXyGT23O aDTGI+e/0mUPQlAP0Pl8XSIQbcW53XJWmSeiIw5O24TMDRAIJHb07Awag4ymE3SJ vU3PyEYWAyRAYuJLGLsjMH/xQgP5Xc1iDANB+jrgWIv1wWAIB6CDzDXrASB+j6wc 8l8DVRMLPS5Trh+0i8GEsoRUFiTlFzfSyu7XqbDCLgc7Nft+pHibmCGVlOT4Zzbz Kh2v1U+B5leSEx8tDxaHrHDOPbw2ubgJJx4gyGllcG8rwxaWVKQF6t70sXPyh+/u AZxRJpOKIWBjO/dvs8Oh6eF3n7cV6N8ZtQX6R7ZZH4fUXNe2VhLNhsz5xzaU0ABW kcq2EXzZfG/TVb5/H0GQA

Copy: 1105153@bugs.debian.org
Copy: sanvila@debian.org (Santiago Vila)

Hi Otto,

On Wednesday, 14 May 2025 4:24:02 AM AEST Otto Kekäläinen wrote:

While I disagree on what is an optimal workflow, I appreciate that you
have documented at https://salsa.debian.org/onlyjob/notes/-/wikis/home
your workflow, and what your experience was with the other tools and
the issues you ran into. A lot of people just state their opinions
without detailing what problem they exactly ran into, nor presenting
what their alternative solution is.

Thanks. Though I wish you had a little more faith in my experience... ;)

I have more unwritten material on the subject, like cases where GBP is
not merely suboptimal but outright inappropriate, harmful, or impossible
(or at prohibitively difficult) to use.

Perhaps one day I will do a writeup that explains how to efficiently
use `git reset --hard` in the gbp context, how to use `git difftool`
to view differences between upstream/Debian or various Debian releases
in Meld, and in general how to use gbp now in 2025. I think that one
of the biggest shortcomings in git-buildpackage has been that the documentation historically has only listed options on what is
possible, without actually listing the exact commands Debian
maintainers should be repeatedly using in dally work to review package history, prepare new upstream imports, submit Merge Requests,
efficiently git amend and rebase, force push new versions for
re-review, how to efficiently prepare stable and oldstable updates in parallel without duplicating work etc.

It would be great if you do such writeup, but IMHO it is actually a part
of the problem: GBP workflow is so sophisticated that it requires much experience as well as esoteric knowledge -- all that is especially
difficult for newcomers as it wastes a lot of effort for little benefit
even as convention.

And even without some advanced git skills, GBP workflow can be grinding
and tedious, like when you repeat commit-ammend steps many times when
testing and staging changes, instead of committing finished work once
when it is done.

We have ventured quite clearly outside a regular bug report
discussion, so I will end here. Just to clarify: I am not doing any
changes to the gocryptfs package or repository, and nobody is planning
to remove the origtargz fallback in Salsa CI. I am just saying that
this repo layout is not ideal in my view, and I would feel severely
limited if I had to maintain a package without access to upstream
source in-place or upstream git history.

Indeed. As my closing comment I just want to add that if you think that "upstream source in-place or upstream git history" are useful then they
are, and you should have them at your convenience as local branches.

As for myself, I tend to have a fork of upstream github project with
"upstream" branch following upstream repository as a _separate_ repo.
I do not want to have one repository tracking my github fork, upsteam
repo, and Salsa packaging all in one repository.
Also, merging upstream history with history of Debian packaging is
harmful because packaging and upstream development are distinctly
different tasks.

I hope at least some of that makes sense.
Thank you for your help and attention.

--
Kind regards,
Dmitry Smirnov
GPG key : 4096R/52B6BBD953968D1B

---

The greater the state, the more wrong and cruel its patriotism, and the
greater is the sum of suffering upon which its power is founded.
-- Leo Tolstoy

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEULx8+TnSDCcqawZWUra72VOWjRsFAmgkI1wACgkQUra72VOW jRtP2Q/+NUBa5w5Fvdexao0VvHAo6u9u68HRWNS5kjRgKIxNS5BuKxPS5Vnz54Pq KncXklBoTAM+78xMJ54NJvOvRoRh1BZaFxu30Cc8ECZRfy0MqpVUwkHyg7L+5gnj IdUyyIH+KyRiPNoeDywTQxm5XJj7CvpFpDCeVBszdsV4jzbwyYg8WI3EPPscH96i 0csoQbSMi0qvsls1L5ZBt+7andQ6wgSJULpTeGKa2E/REESqycMmHu0OWTPv6El8 E0us8Kw9Lv4W7TSiz18JLZLRO7ldBjaazJL/lhypX1V80PbTqF2PoeLZT8CDdQER XiqOcisOYxUfoQKBO77ntkk7mErdBwQwzGFIGMYNlBLm7QxOt67l4EQcXeUitGRN VthbkoY8v9YN/Qee9UsDs9qaKD3WmGnpTDR/7zEFpLGNF4jctxaIPSwSmvd0eGc5 +IhBsVds84u+LACT7ylkguDn4MZQutfvvMaPan6Hy1b0suAnDn3ee+PZfbMHRuQ1 2DqtjsgPj1K5CthOmg0TfAvkwzq5/EPzJ5s8Fzxa79mA1HMebByrP0GzAn5M7RK9 No6FVlovxpkfiOk9S1ie1owUHMHO/E99Rh6dzWuA/lnYpfjCNp/39z3X6zlizgMk sXEtdRBBEU80h7+ayeU222PVBf