Jérémy Lal <kapouer-QATUhw8NPUbYtjvyW6yDsg@public.gmane.org> writes: > Hi, > > some remarks below: Thank you! I'm following up one two items that are resolved below. I'm still working to resolve the other dependencies, and I will followup on those separately when I have something to add to discussion. >> 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. Fortunately, I realized that rekor needs very little from relic. I have now uploaded relic to NEW containing only a quite stripped down relic library: https://salsa.debian.org/go-team/packages/relic/-/commit/00e505565d5bfc8903b6a056979abe2982befcdc Relic looks useful on its own, so I hope to revisit the package (or someone else could work on it) but fortunately it seems we can get relic into a usable state for rekor. Relic had several dependencies that I packaged which may now not be needed after all. I won't do source-only uploads until I've confirmed that dependencies are needed by rekor, and will open RC bugs on any packages that remains too. Some of the packages I added looks useful on their own, though, but if nobody else cares about them, and rekor doesn't need them, let's keep them out of trixie. >> 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 I discovered that rekor use sigs.k8s.io/release-utils quite for its "rekor-cli version" ASCII art output: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060840#30 However after excluding the mage stuff, the package built easily and is now in unstable in good shape: https://tracker.debian.org/pkg/golang-k8s-sigs-release-utils /Simon
Attachment:
signature.asc
Description: PGP signature