• Bug#1105153: gocryptfs: Salsa CI is failing

    From Santiago Vila@21:1/5 to All on Mon May 12 13:50:01 2025
    Package: src:gocryptfs
    Version: 2.5.1-2

    Hello.

    I've just converted the NMU Adrian did for this package
    into a team upload, because that way the changes fit better
    in salsa, as they are granular.

    While in an ideal world I would not have uploaded before
    a green pipeline in salsa, time constraints do now allow
    me to do that right now.

    I'm filing this report in the hope that the Salsa CI can
    be fixed, and also if some kind soul can explain to me
    what was wrong and how to fix it, I'd like to know.

    (In particular, I miss the "build on i386" which I see
    in other pipelines).

    (I'm using x-debbugs-cc: Otto, as he likely knows).

    Maybe the number of failing pipelines in the team
    is too high for bugs like this to make sense at all.
    If that's the case, I apologize.

    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?@21:1/5 to All on Mon May 12 20:10:01 2025
    Checking:

    - https://tracker.debian.org/pkg/gocryptfs says 2.5.1-2 was uploaded
    today, i386 build passed at https://buildd.debian.org/status/package.php?p=gocryptfs
    - https://salsa.debian.org/go-team/packages/gocryptfs has 2.5.1-2 as
    latest commit
    - repo user branch 'master' and hosts only the debian/ subdirectory
    - https://salsa.debian.org/go-team/packages/gocryptfs/-/blob/master/debian/gbp.conf
    is forbidding use of pristine-tar, yet not using upstream tags either,
    so no security features in use
    - https://salsa.debian.org/go-team/packages/gocryptfs/-/pipelines/864484
    is not running Salsa CI
    - custom go test failing on:

    gbp:info: Tarballs 'gocryptfs_2.5.1.orig.tar.gz' not found at '/nonexistent' gbp:error: upstream/2.5.1 is not a valid trees

    If you adopt a sensible git structure and have gbp.conf configured, I
    can take a look. Otherwise I am just wasting effort debugging someones
    custom structures.

    Here is a general primer into what the various branches in Debian / git-buildpackage are and what they are used for: https://optimizedbyotto.com/post/debian-source-package-git/

    If you want to help me with Salsa CI, the pipeline should also adopt
    Salsa CI first. This is the CI file the repository is currently
    configured to use: https://salsa.debian.org/go-team/packages/gocryptfs/-/blob/master/debian/gitlab-ci.yml

    I would recommend going forward that you push to Salsa first, wait for
    CI to pass, and if it didn't, re-iterate until it passes.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Santiago Vila@21:1/5 to All on Tue May 13 01:00:02 2025
    El 12/5/25 a las 20:05, Otto Kekäläinen escribió:
    If you want to help me with Salsa CI, the pipeline should also adopt
    Salsa CI first. This is the CI file the repository is currently
    configured to use: https://salsa.debian.org/go-team/packages/gocryptfs/-/blob/master/debian/gitlab-ci.yml

    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.

    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, and Salsa CI seems to be smart
    enough that it can build the package now.

    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.

    Thanks a lot.

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