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