Hi,

some remarks below:

Le lun. 15 janv. 2024 à 21:16, Simon Josefsson <si...@josefsson.org> a
écrit :

> Hi
>
> I want to get Sigstore's rekor <https://github.com/sigstore/rekor> into
> Debian so that <https://gitlab.com/debdistutils/apt-sigstore> can be
> included.  I'm new to Go and how Debian approaches Go code, but have
> made some progress.  I'm now stuck.  This e-mail summarize the open
> issues.  Can someone take a look and help me?  If you want, feel free to
> push to any of the git repositories below with improvements.
>
> My rekor packaging lives here, including its pipeline:
>
> https://salsa.debian.org/jas/golang-github-sigstore-rekor/
> https://salsa.debian.org/jas/golang-github-sigstore-rekor/-/pipelines
>
> It is a fork of an earlier unfinished attempt that lives here, I hope to
> merge back things once they work:
> https://salsa.debian.org/go-team/packages/golang-github-sigstore-rekor
>
> Latest build attempt of rekor:
>
> https://salsa.debian.org/jas/golang-github-sigstore-rekor/-/jobs/5162176
>
> It raises errors about the following dependencies:
>
> github.com/sassoftware/relic
> github.com/in-toto/in-toto-golang
> sigs.k8s.io/release-utils
> github.com/google/trillian
> github.com/sigstore/sigstore
> google.golang.org/grpc
>
> Let's go through them one-by-one.
>
> GITHUB.COM/SASSOFTWARE/RELIC
>
> Packaging is here:
> https://salsa.debian.org/go-team/packages/relic
>
> Latest build output:
> https://salsa.debian.org/jas/relic/-/jobs/5162602
>
> Fails like this:
>
> # github.com/sassoftware/relic/cmdline/remotecmd
> src/github.com/sassoftware/relic/cmdline/remotecmd/azure.go:65:20: cannot
> use &dvCache{…} (value of type *dvCache) as cache.ExportReplace value in
> argument to public.WithCache: *dvCache does not implement
> cache.ExportReplace (wrong type for method Export)
>                 have Export(cache.Marshaler, string)
>                 want Export(context.Context, cache.Marshaler,
> cache.ExportHints) error
> src/github.com/sassoftware/relic/cmdline/remotecmd/azure.go:79:12: not
> enough arguments in call to s.cli.Accounts
>         have ()
>         want (context.Context)
> src/github.com/sassoftware/relic/cmdline/remotecmd/azure.go:79:12:
> assignment mismatch: 1 variable but s.cli.Accounts returns 2 values
>
> The reason seems to be that our
> golang-github-azuread-microsoft-authentication-library-for-go-dev is too
> new.  Should we package an older version?


> I have opened an upstream bug about this requesting them to use a newer
> dependency:
>
> https://github.com/sassoftware/relic/issues/39
>
> Looking at the API changes, I think this could be patched easily by
> somehow who knows Go.  Is that the right approach?  Patches welcome.
>

It's not so straightforward because azure bumped its API and did breaking
changes.
I had the same problem in python recently.


GITHUB.COM/IN-TOTO/IN-TOTO-GOLANG
>
> Packaging is here:
> https://salsa.debian.org/go-team/packages/in-toto-golang
>
> Latest build output:
> https://salsa.debian.org/jas/in-toto-golang/-/jobs/5162631
>
> src/github.com/spiffe/go-spiffe/v2/bundle/jwtbundle/bundle.go:10:2:
> cannot find package "github.com/go-jose/go-jose/v3" in any of:
> src/github.com/spiffe/go-spiffe/v2/svid/jwtsvid/svid.go:8:2:
> cannot find package "github.com/go-jose/go-jose/v3/jwt" in any of:
> src/github.com/spiffe/go-spiffe/v2/workloadapi/client.go:20:2:
> cannot find package "google.golang.org/grpc/credentials/insecure" in any
> of:
>
> We depend on golang-github-go-jose-go-jose-dev which provides v3.0.1 --
> https://tracker.debian.org/pkg/golang-github-go-jose-go-jose -- why
> isn't it picked up?
>
> The google.golang.org/grpc dependency is probably too old, needs to be
> fixed here and already discussed on the mailing list fairly recently:
> https://tracker.debian.org/pkg/golang-google-grpc
>
> SIGS.K8S.IO/RELEASE-UTILS
>
> Packaging is here:
> https://salsa.debian.org/go-team/packages/golang-k8s-sigs-release-utils
>
> Latest build output:
> https://salsa.debian.org/jas/golang-k8s-sigs-release-utils/-/jobs/5162686
>
> There is discussion about this one here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060840
>
> Can we avoid this dependency by patch rekor?  That would be nice since
> it seems like a problematic package.  It needs
> github.com/uwu-tools/magex and github.com/common-nighthawk/go-figure
> that are not packaged.
>

Yes, you should be able to get rid of it.
This is an example of how to inject the version, it might work well with
DEB_UPSTREAM_VERSION
https://github.com/ansible/receptor/blob/6494b00a36df0a8b4fdf895a962a985d03d33f76/Makefile#L50


> GITHUB.COM/GOOGLE/TRILLIAN
>
> Packaging is here:
> https://salsa.debian.org/go-team/packages/trillian/
>
> Latest build output:
> https://salsa.debian.org/jas/trillian/-/jobs/5162705
>
> Dependency problems:
>
> google.golang.org/grpc/credentials/insecure
> go.etcd.io/etcd/client/v3
> contrib.go.opencensus.io/exporter/stackdriver
> github.com/cockroachdb/cockroach-go
> github.com/apache/beam
> go.etcd.io/etcd/server
>
> The grpc is already mentioned.
>
> The etcd I don't understand, the package depends on
> golang-etcd-server-dev that despite its name appears to include the
> client.  Why isn't it picked up?
>

Probably a version discrepancy.
Check
/usr/lib/go-1.21/src/go.etcd.io/etcd/server/v3/embed

In general you need to check each missing paths for clues.
It's cumbersome, but usually fixable. Golang is not as bad as it seems :)

Same regarding contrib.go.opencensus.io/exporter/stackdriver, we depend
> on golang-go.opencensus-dev that seems to have it.
>
> Finally github.com/apache/beam seems like a huge project, I haven't
> started looking at it.  Can it be avoided somehow?
>
> GITHUB.COM/SIGSTORE/SIGSTORE
>
> Packaging is here:
> https://salsa.debian.org/go-team/packages/golang-github-sigstore-sigstore
>
> I believe it may be as simple as upgrading it to the latest version:
>
> https://tracker.debian.org/pkg/golang-github-sigstore-sigstore
>
> I haven't looked into that yet since I haven't worked out a method to
> rebuild all reverse dependencies for a package.
>
> GOOGLE.GOLANG.ORG/GRPC
>
> Already discussed earlier under in-toto-golang.
>

Same problem. We have ratt in golang but it's so old.

Jérémy

Reply via email to